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1.  INTRODUCTION 

Communication  protocols1  are  widely  used  in  computer-tc-computer  information 
transmission  for  routing,  error  detection  and  Sow  control.  Many  protocols  (computer  and 
non-computer)  have  been  proposed  over  the  past  several  decades.  The  earliest  technical 
protocols  dealt  with  telegraph-like  communication  [Fah74];  early  hardware  was  typically  used 
to  send  "messages"  to  a  receiver  via  a  series  of  shocks,  since  the  light  bulb  and 
electromagnetic  relay  were  invented  years  after  these  original  protocols.  Later  techniques 
used  magnetically-operated  levers  and  signals  to  send  letters  and  numerals  using  some 
ingenious  and  compact  methods2.  Protocols  proposed  over  the  last  several  years  have 
steadily  increased  in  complexity  to  better  use  the  available  communication  media  and  to 
handle  an  increasing  volume  of  information. 

This  work  reports  on  an  existing  basic  communications  protocol  and  then  extends  that 
protocol  with  previously  published  mechanisms  [Tan81,  Bla83,  Dav83].  The  analysis  of  the 
extended  protocol  and  it's  implementation  in  a  concurrent  language  environment  (Concurrent 
C)  are  also  described.  The  environment  also  provides  an  interface  for  testing  this  and  other 
protocol  implementations  within  a  limited  architecture.  Several  scenarios  are  presented  to 
show  that  the  enhanced  protocol  recovers  properly  from  "seeded"  errors. 

The  work  has  application  in  the  areas  of  interprocessor  communication  and  data 
transmission.  Since  the  protocol  provides  "reliable"  node-to-node  transmission  of  data,  it  is 
possible  to  use  it  as  part  of  a  reliable  terminal-to-mainframe  communication  protocol.  The 


1.  PmtorftU  arr  «V niles  imrl  tiuivriuinnK  irnrt^  tr,  rtimmmirti-  hww  MttHafJMBWMI 

2.  One  suck-  protocol's  summary  ended  "With  such  an  apparatus  no  errors  could  possibly  occur,  for  everything  went  like  clockwork  ," 
[  Amy38]  Others  believed  "...success. ..would  likewise  depend  on  an  apparatus  liable  to  10  infinite  nuiuLiu  of  aeddemi,  scarce  in 
the  power  of  human  foresight  to  guard  against."  !Gam97]    Protocol  designers  should  keep  the  latter  comment  in  mind. 


concurrent-language  test-bed  offers  a  mechanism  to  test  new  protocol  implementations  at  the 
"user"  level  without  the  need  to  create  a  new  test  environment. 

Chapter  2  summarizes  a  portion  of  the  abundant  literature  on  communication  problems  and 
protocol  analysis  and  design.  The  basic  protocol  mentioned  above  is  also  described  in  some 
detail.  In  Chapter  3,  some  possible  extensions  to  the  basic  protocol  are  presented.  Some  of 
these  extensions  are  then  integrated  into  the  basic  protocol,  and  an  analysis  of  the  enhanced 
protocol  is  presented.  Chapter  4  offers  a  concurrent  language  implementation  of  the 
enhanced  protocol  together  with  a  test  generator/monitor.  The  conclusions  in  Chapter  5  also 
present  some  areas  for  further  investigation  and  discuss  other  implementation  possibilities. 
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2.  EXISTING  LITERATURE 


Communication  protocols  and  their  analysis  have  been  a  topic  of  a  large  volume  of 
literature,  both  in  book  and  journal  form.  Unfortunately,  much  of  the  design  and 
implementation  of  protocols  was  originally  performed  by  equipment  manufacturers,  with  the 
usual  results:  Each  manufacturer  used  a  private  protocol,  incompatible  with  all  others. 
Eventually,  the  major  manufacturers'  (primarily  IBM  and  Digital  Equipment)  protocols 
became  de  facto  standards.  The  literature  reflected  this  proliferation  of  standards  by  using 
inconsistent  and  ambiguous  terminology.  Attempting  to  define  a  "common  ground"  for 
discussion,  several  standards  organizations  together  created  an  architectural  model  for 
communication  processes.  The  result  is  called  the  Reference  Model  of  Open  Systems 
Interconnection  (hereafter  called  the  OSI  Model),  sponsored  by  the  International  Standards 
Organization.  [Zim80] 

2.1   OSI  Model 

To  place  the  protocols  mentioned  below  into  their  proper  perspective  relative  to  the  overall 
process  of  communication,  the  OSI  Model  will  first  be  summarized.  The  OSI  Model 
architecture  partitions  communication  into  seven  layers.  Within  an  entity  (also  called  a 
node),  each  numbered  layer  "interfaces"  functionally  only  with  its  adjacent  layers  by 
providing  services  to  the  layer  above  and  using  services  of  the  layer  below.  Communication 
between  entities  logically  takes  place  only  between  like-numbered  layers  using  a  protocol  for 
that  layer.  These  protocols  operate  using  the  services  provided  by  the  next  lower  layer.   The 

defined  layers  and  their  numbers  are: 

Application  Layer  (7)  -  provides  support  directly  to  the  Application  Processes  executing 
across  the  various  communicating  entities  (for  example,  process  synchronization). 
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Prescntation  Layer  (6)  -  provides  data  transformations  between  Application  Processes  (e.g., 
compaction/expansion). 

Session   Layer  (5)  -  provides  the  "dialogue"  connection  between  pairs  of  Application 
Processes  (via  Level  6)  and  the  capability  to  establish  the  connection. 

Transport  Layer   (4)  -   provides  reliable  end-to-end  transmission  of  messages  between 
communicating  processes. 

Network  Layer  (3)  •  provides  the  means  for  sending  messages  between  any  pair  of  entities 
within  the  network,  typically  providing  routing  and  flow  control  on  an  end-to-end  basis. 

Link  Layer  (2)  -  provides  the  means  to  reliably  exchange  sequences  of  messages  between 
directly-connected  entities. 

Physical  Layer  (1)  -  provides  the  electrical  and  mechanical  connection  between  entities  and 
services  to  the  Link  layer  allowing  message  transmission. 

Typically,  a  message  from  a  higher-numbered  layer  is  transported  by  prefixing  a  layer 
"header"  to  the  message  and  sending  the  message  to  the  next  lower  layer.  Message  reception 
operates  in  the  reverse  order,  receiving  messages  from  the  lower  layer,  removing  and 
processing  the  layer  "header"  and  delivering  the  remaining  portion  of  the  message  to  the  next 
higher  layer. 

2.2  Link  Layer 

This  paper  will  be  primarily  concerned  with  protocols  at  the  Link  layer  (Layer  3).  Thus 
issues  such  as  physical  media  (Layer  1)  and  routing  (Layer  3)  will  not  be  covered.    To 

provide  services  to  the  Network  layer  as  mentioned  above,  the  Link  layer  must  be  able  to: 

1 .  identify  or  address  the  required  physical  unit  for  transmission, 

2.  maintain  a  logical  sequence  of  messages  for  each  logical  data  link, 

3.  handle  errors  in  message  ordering  and  transmission  and 

4.  control  the  flow  of  messages  on  the  physical  connection. 

These  capabilities  are  provided  by  "framing"  the  messages  into  blocks  that  have  a  structure 
determined  by  the  protocol.    The  Link  layer  sends  and  receives  these  frames  3  through 


services  provided  by  the  Physical  layer.  The  Physical  layer's  primary  service  is  the 
transmission  of  bit  or  character  streams  over  a  logical  link. 

The  Link  layer  of  a  particular  network  topology  is  influenced  by  that  topology,  even  though 
routing  through  the  network  is  not  a  function  of  this  layer.  This  is  because  connections  other 
than  node-to-node  (i.e.,  between  directly  connected  entities)  are  supported  by  the  OSI 
Model.  These  other  connections  are  termed  multipoint;  this  type  of  Link  layer  connection  is 
not  covered  in  this  paper.  Node-to-node  connections  at  the  Link  layer  are  'logical  links"  in 
that  one  real  transmission  path  may  support  several  logically  distinct  connections  between  the 
same  pair  of  nodes.  The  interface  between  the  Link  layer  and  the  Physical  layer  would,  in 
this  case,  require  a  logical  link  identification  on  every  exchange  of  information  to  maintain 
the  logical  link  association.  Within  the  node-to-node  type  of  connection,  two  methods  of 
"framing"  the  messages  are  commonly  used.  One  of  these  is  known  as  character-oriented; 
the  other  is  called  bit-oriented. 

The  bit-oriented  protocols  are  newer  and  have  several  advantages  over  the  character-oriented 
protocols.  The  basic  unit  in  the  frame  is  a  bit;  certain  bit  sequences  are  used  to  detect  the 
beginning  and  ends  of  frames.  The  frame  can  typically  contain  any  number  of  bits.  These 
protocols  are  inherently  transparent  to  character  set  size  and  codes  through  the  use  of  a 
technique  called  "bit-stuffing."  (This  replaces  certain  bit  sequences  with  other  sequences  that 
have  extra  zero  bits  within  them,  thus  preventing  the  framing  bit  sequences  from  appearing 
within  the  unit  sent  to  the  Physical  layer.)   The  bit-manipulation  required  (monitoring  for 


3.    The  term  frame  h  used  in  tins  chapter  to  refer  to  data  units  exchanged  between  nocks  at  the  Link  layer.   The  OSI  Model's 
corresponding  term  is  'phvsicaMayer-Kervic^oata-iinil,"  but  one  suspects  tins  is  somewhat  shortened  in  informal  conversation. 


special  bit  sequences  and  shifting  to  add  or  delete  the  extra  zero  bits)  almost  forces  the  Link 

layer  (or  a  portion  of  it)  into  hardware;  the  overhead  on  general-purpose  computers  would 

overcome  most  of  the  advantages.  Some  examples  of  bit-oriented  protocols  are: 
HDLC       (High  Level  Data  Link  Control)  -  part  of  ISO  X.25, 
ADCCP     (Advanced  Data  Communication  Control  Protocol)  -  ANSI, 
SDLC        (Synchronous  Data  Link  Control)  -  part  of  SNA  from  IBM, 
BDLC       (Burroughs  Data  Link  Control)  -  Burroughs  and 
UDLC       (Univac  Data  Link  Control)  -  Univac. 

23  Character-oriented  protocols 

Character-oriented  protocols  are  based  on  characters  as  the  unit  of  transmission.  Typically,  a 
small  set  of  seldom-occurring  characters  are  chosen  as  "control"  characters.  The  occurrence 
of  these  characters  in  the  input  is  used  to  delimit  and  define  the  frame  sent  between  nodes  at 
the  Link  layer.   The  following  functions  are  basic  [Con80]  to  character-oriented  Link  layer 

protocols: 

1.  Framing  places  a  structure  on  the  character  stream  received  from  the  Physical  layer  by 
identifying  the  beginning  and  end  of  frames. 

2.  Error  Detection  provides  a  means  to  determine  if  frames  were  altered  in  transmission. 
It  also  provides  for  detection  of  out-of-order  frames. 

3.  Recovery  controls  the  actions  taken  to  recover  from  errors  and  lack  of  response  from 
the  connecting  node. 

4.  Flow  Control  handles  the  rate  of  character  flow  between  nodes. 

5.  Link  Control  allows  the  connection  between  nodes  to  be  established  and  terminated. 

Each  function  will  be  described  in  some  detail  below,  except  for  Flow  Control,  which  is 
typically  handled  by  ignoring  frames  that  the  node  is  not  prepared  to  receive.  Also,  a 
Transparency  function  is  provided  by  many  character-oriented  Link  layer  protocols;  this 
allows  "control"  character  bit  sequences  to  be  sent  as  data  without  being  considered  "control" 
characters  by  the  Framing  function. 
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Framing  is  accomplished  by  using  a  particular  "control"  character  to  identify  the  beginning  of 
a  frame.  The  end  of  the  frame  is  identified  either  by  a  different  "control"  character  or  by  a 
character  count  contained  within  the  frame.  (The  latter  method  is  usually  called  a  byte-count 
character-oriented  protocol.)  The  Framing  function  scans  the  incoming  characters  from  the 
Physical  layer  for  the  beginning-of-frame  character.  Everything  after  that  until  an  end-of- 
frame  character  (or  the  number  of  characters  in  the  character-count)  is  considered  a  frame. 

Error  Detection  of  transmission-induced  alterations  to  the  frame  is  commonly  performed  by 
checksums.  A  checksum  is  the  result  of  a  computation  over  the  characters  in  the  frame.  The 
checksum  is  sent  with  the  frame;  on  receipt,  the  checksum  computation  is  performed  again 
and  compared  to  the  transmitted  checksum.   The  frame  is  considered  "damaged"  if  the  two 

checksums  are  not  equal4.  The  most  commonly  known  checksum  methods  are: 

ARPANET  Internet  —  "...the  16-bit  one's  complement  of  the  one's  complement  sum  of  the 
16-bit  of  all  16-bit  words..."  [Pos81], 

CRC-16  —  the  remainder  after  dividing  the  frame,  treated  as  a  single  binary  number,  by  the 
binary  number  11000000000000101,  and 

GCTTT  V.41  -  the  remainder  after  dividing  the  frame,  treated  as  a  single  binary  number,  by 
the  binary  number  10001000000100001. 

The  latter  two  methods  (known  as  Cyclic  Redundancy  Codes)  can  be  shown  [Tan81]  to 
detect  any  odd  number  of  incorrect  bits,  any  two  bits  incorrect,  any  error  contained  within  a 
16  bit  sequence  and  99.998%  of  any  other  random  bit  errors. 

Error  Detection  of  out-of-order  frames  requires  a  sequence  number  field  within  the  frame. 
Each  node  has  a  variable  that  determines  the  next  frame  sequence  number  to  expect  from  a 


4.  It  is  possible  for  the  Physical  layer  to  damage  a  frame  in  such  a  way  that  the  Ijaasssaasaai  win  still  match.  The  aaaaaaaSJas  method 
should  make  that  feasibility  very  remote  by  rirtrrtmE  well  the  most  likely  errors  on  the  particular  type  of  physical  linkisi  used  m 
the  network. 
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connecting  node.  If  a  received  (undamaged)  frame  does  not  contain  the  expected  sequence 
number,  the  frame  is  considered  out-of -sequence.  If  the  sequence  number  is  correct,  an 
acknowledgement  (ACK)  is  sent  back  to  the  transmitting  node  to  indicate  successful 
reception  of  an  in-sequence  frame.  The  transmitting  node  must  retain  all  transmitted 
messages  until  informed  by  the  receiver  that  transmission  of  the  frame  was  successful. 

The  Recovery  mechanism  is  a  major  part  of  a  data  link  protocol.  There  are  many  types  of 
recovery  possible.  The  simplest  mechanism  sends  a  single  frame  and  waits  a  (predetermined) 
length  of  time  for  the  receiver  to  send  back  an  ACK.  Failure  to  receive  the  ACK  will  result 
in  a  "timeout"  of  the  waiting  transmitter  and  retransmission  (and  another  wait)  will  occur. 
This  continues  until  the  frame  is  accepted.  The  receiver  must  continue  to  respond  with  an 
ACK  even  if  the  frame  has  been  successfully  received,  to  insure  that  its  own  ACK  wasn't 
lost.  This  mechanism  is  called  the  stop-and-wait  ARQ  (Automatic  Repeat  Request)  or  PAR 
(Positive  Acknowledgement  with  Retransmission)  method. 

This  can  be  enhanced  somewhat  with  a  negative  acknowledgement  (NACK)  sent  by  the 
receiver  to  inform  the  transmitting  node  that  a  "damaged"  frame  has  arrived.  This  would 
result  in  immediate  retransmission  rather  than  waiting  for  timeout.  Timing  is  still  required 
to  detect  complete  loss  of  the  frame,  ACK  or  NACK. 

Further  improvements  are  possible  only  if  pipelining  of  the  transmitter's  frames  is  allowed; 
this  allows  a  small  number  of  frames  to  all  be  transmitted  without  waiting  for  an  ACK.  The 
number  of  sent  but  unacknowledged  frames  allowed  is  called  the  send  window.  If  the 
receiver  still  insists  that  frames  will  only  be  accepted  in  order,  the  receiver  is  said  to  have  a 
receive  window  of  size  1.  When  the  receiver  sends  a  NACK,  it  will  contain  the  sequence 
number  that  was  last  received  correctly5.    This  allows  the  transmitter  to  determine  from 
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which  frame  to  begin  retransmission.  This  retransmission  strategy  is  called  "Go— Back— N." 
Each  frame  in  the  send  window  must  be  timed  separately.  Timeout  of  a  frame  will  result  in 
the  same  actions  as  receipt  of  a  NACK  indicating  the  frame  was  lost  (i.e.,  the  frame  and  all 
following  frames  will  be  retransmitted). 

If  the  receiver  can  also  accept  some  frames  out-of-sequence  (and  hold  them  until 
predecessors  arrive),  the  receive  window  size  determines  the  number  of  out-of-sequence 
frames  that  can  be  accepted.  However,  the  receive  window  cannot  be  larger  than  N/2  where 
N  is  the  number  of  unique  sequence  numbers.  With  such  a  receive  window,  an  improved 
retransmission  strategy  called  "Selective  Repeat"  may  be  used.  The  transmitter,  on  receipt  of 
a  NACK+sequence  number,  can  retransmit  only  the  next  frame  in  the  sequence.  If  that 
frame  was  the  only  missing  one,  the  receiver  will  ACK  with  a  sequence  number  that 
acknowledges  the  retransmitted  frame  and  the  frames  that  the  receiver  had  previously 
accepted  out  of  order.  Timeout  of  a  frame  would  result  in  retransmission  of  only  that  frame. 

Another  enhancement  possible  with  pipelining  is  called  piggybacking.  This  allows  an 
ACKed  sequence  number  to  be  placed  in  data  frames  that  are  being  transmitted  back  to  the 
original  sending  node,  thus  avoiding  the  transmission  of  a  separate  ACK  frame.  Since  the 
ACKed  sequence  number  typically  is  only  a  few  bits  in  size,  there  is  little  frame  overhead 
involved  in  this  enhancement.  However,  to  fully  exploit  piggybacking,  the  receiving  node 
must  delay  transmitting  ACKs  for  a  time  to  allow  transmission  requests  in  the  reverse 
direction  to  arrive.  If  there  is  no  reverse  traffic,  then  an  ACK  must  be  transmitted  or  the 
protocol  will  eventually  lockup"  (i.e.,  stop  sending  new  frames).   Delaying  for  a  period  of 

S.     Some  protocols  indicate  the  icqucice  nianta  eiperud  wi,  tiwtcfid  of  the  last  rrcrrvtd  number 
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two  or  three  ACKs  has  been  shown  [Lai82]  to  result  in  a  significant  amount  of  piggyback 
utilization,  if  the  send  window  is  of  size  4  or  more.  If  the  number  of  "accumulated"  ACKs  is 
allowed  to  equal  the  window  size,  lockup  will  occur  until  some  reverse  traffic  appears. 

Link  Control  provides  the  mechanism  needed  to  establish  a  connection  over  a  link  or  to 
disconnect  such  a  connection.  The  protocol  attempts  to  keep  both  ends  of  a  link  either 
"connected"  or  "disconnected."  In  the  disconnected  state,  no  Network  layer  requests  (except 
for  connection)  are  accepted;  most  frames  from  the  link  receive  a  "I'm  disconnected" 
response.  Requests  for  disconnect  while  in  the  connected  state  may  be  honored  immediately 
or  may  be  deferred  until  there  are  no  further  unacknowledged  frames  at  either  end  of  the 
link.  Link  Control  must  also  handle  the  case  of  a  request  for  connect  or  disconnect  when  the 
state  is  already  connected  or  disconnected,  respectively. 

Transparency  is  inherent  in  the  byte-count  protocols,  but  requires  an  "escape"  mechanism  in 
other  character-oriented  protocols.  The  escape  mechanism  operates  by  replacing  "control" 
characters  in  the  frame  with  a  sequence  of  characters  before  transmission.  The  character 
sequences  are  replaced  with  the  original  characters  when  the  frame  is  received.  This  is  called 
"character— stuffing,"  in  analogy  to  the  "bit— stuffing"  of  bit-oriented  protocols. 

2.4  Examples  of  character-oriented  protocols 

Most  of  the  earliest  computer-communication  protocols  were  character-oriented.  The  early 
teletype  networks  used  5  or  6  bit  Baudot  codes  with  embedded  control  characters  to  control 

the  receiving  devices.  A  list  of  major  computer-to-computer  protocols  includes: 

BISYNC  (IBM's   Binary   Synchronous   Communication   protocol)   is   widely   used, 

particularly  in  a  multi-point  configuration  to  handle  groups  of  remote 
terminals.  The  node-to-node  version  operates  over  half-duplex  lines. 

X3.28  (ANSI's  protocol)  standardizes  on  10  ASCII  control  characters  for  link 

control    and    specifies    several    variations    of    a    protocol    for    different 
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configurations  and  applications. 

IMP-to-IMP  (ARPANETs  sub-network  protocol)  has  operated  for  15  years  providing 
service  to  well  over  100  host  computers.  It  operates  8  logical  links  over 
each  physical  link  using  a  stop-and-wait  protocol.  NACK  is  not  used,  but 
the  piggybacked  acknowledgement  field  does  contain  the  last-correctly- 
received  frame  number. 

DDCMP  (Digital  Equipment's  Digital  Data  Communications  Message  Protocol)  uses 

the  byte-count  mechanism  to  achieve  data  transparency. 

Other  protocols  that  are  less  well-known  usually  use  only  minor  modifications  of  the  previous 
protocols.  However,  some  notable  exceptions  to  this  have  been  implemented.  The 
MININET  [Ner84]  local  area  network  uses  continuous  transmission  of  short  (32  bit)  fixed- 
length  frames  to  achieve  a  'lock-step"  form  of  operation.  By  establishing  a  count  of  the 
number  of  frame  periods  required  to  send  and  receive  initialization  frames,  each  node  can 
determine  the  number  of  frames  always  in  transit  between  itself  and  another  connecting 
node.  No  ACK  or  NACK  control  frames  exist.  Receipt  of  a  damaged  frame  is  indicated  to 
the  transmitter  by  having  the  receiver  backing  up  its  own  frame  sequence  by  the  number  of 
transit  frames  +  1,  and  retransmitting  frames  from  that  sequence  number  forward.  The 
transmitter,  on  receipt  of  an  out-of-sequence  frame,  backs  up  an  amount  determined  by  the 
out-of-sequence  frame  number  and  the  frame  number  it  expected  to  receive. 

The  French  NADIR  satellite  link  protocol  [Ner84]  uses  explicit  ACKs  for  every  undamaged 
frame  received,  regardless  of  order.  However,  the  ACK  contains  two  sequence  numbers  and 
acknowledges  receipt  of  all  frames  between  those  two  numbers.  Thus  the  transmitter  can 
determine  which  frames,  if  any,  have  been  lost  or  damaged  and  can  thus  retransmit  them 
immediately.  There  is  little  need  for  a  NACK  with  this  method.  In  heavy  traffic,  the  ACK 
for  the  following  frame  will  indicate  a  missing  frame.  In  light  traffic,  a  timeout  will 
eventually  cause  the  frame  to  be  retransmitted;  in  light  traffic  the  time  saved  by  a  NACK 
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would  have  little  impact. 

2  J  Comer's  Protocol  —  Overview 

Comer,  in  an  excellent  book  describing  both  a  layered  approach  to  and  implementation  of  an 
operating  system  design  [Com84],  presented  a  simple,  effective  data  link  communication 
protocol.  The  protocol  was  presented  in  two  sub-layers  called  Data  link  level  and  Frame 
level6.  Comer's  levels  together  approximate  the  OSI  Model's  Link  layer.  The  Data  link 
level  is  also  similar  to  the  Media  Access  Control  sub-layer  of  IEEE  Standard  802  [IEE84] 
with  the  Frame  level  acting  as  the  IEKE802  Link  Level  sub-layer.  However,  Comer's  Frame 
level  protocol  contains  somewhat  different  capabilities  than  the  IEEE802  Link  Level  sub- 
layer, since  the  latter  has  a  virtual  connection  service  available  to  higher-numbered  layers. 
Comer's  Frame  level  protocol  does,  however,  offer  reliable  transport  of  individual  data 
packets7  with  no  lost  or  out-of-order  packets.  (Detection  of  duplicates,  if  needed,  must  be 
performed  at  a  higher  layer.) 

Comer's  protocol  is  based  on  a  particular  processor  inter-connection  scheme  called  a 
unidirectional  ring-shaped  network.  Each  processor  (or  machine)  in  the  network  has  an 
asynchronous,  full-duplex  bit-serial  connection  to  two  other  processors8.  The  processors  and 
connections  together  form  a  ring  over  which  "frames"  of  character  data  are  transmitted.  One 
connection  on  each  machine  is  considered  the  input  port  and  is  connected  to  the  output  port 


6.  The  phrase  "Data  Link  levd"  will  be  used  to  refer  to  Coma's  *suo-layer*  and  it's  extension  in  the  next  chapter  The  phrase  "Link 
layer"  will  be  used  to  refer  to  that  layer  in  the  061  Mood. 

7.  A  "packet*  is  the  unit  of  oats  exchanged  it  the  Network  layer.  It  is  also,  is  this  paper,  used  to  describe  the  data  the  aaer  wishes 
to  send  buimi  two  process  existing  on  different  physical  ««*i~«  In  effect,  this  lumps  an  data  transenissioo  leuucau  to  the 
Link  layer  from  higher  layers  into  the  term  "packet,*  regardless  of  the  source  of  the  data. 

8.  It  is  poeaibie  for  one  machine  to  be  in  more  than  one  ring,  thus  allowing  it  to  be  used  as  a  "gateway"  for  communication  bjsiui 
the  rings.  That  canabdlitv  does  not  affect  the  protocol  used  over  a  -ingle  link,  since  the  ro-ning  between  networks  is  a  function  of 
the  Network  layer. 
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of  a  "neighboring"  machine.  The  other  connection  is  the  output  port  and  connects  to  the 
input  port  of  a  (usually)  different  machine.  The  flow  of  data  messages  between  machines  is 
always  in  one  direction,  and  response  characters  (for  ACK,  etc.)  are  sent  only  in  the  reverse 
direction. 

The  general  format  of  a  frame  in  Comer's  protocol  is  shown  in  Figure  1  along  with  the 
general  interconnection  of  processes. 
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Application  processes  request  the  transmission  of  packets  to  other  machines  on  the  ring. 
These  packets  are  placed  into  frames  and  transmitted  via  the  output  port.  Transmitted 
frames  are  received  at  the  input  port  of  the  "next"  machine  on  the  ring,  validated  and 
examined  to  determine  their  source  and  destination.  An  ACK  is  sent  back  to  the 
transmitting  machine  to  indicate  the  frame  was  successfully  received.  Frames  destined  for 
the  receiving  processor  are  passed  "up"  a  layer  to  a  process  that  distributes  the  frames  to 
various  other  application  processes.  Frames  not  destined  for  the  receiving  processor  are 
usually  forwarded  via  the  output  port  to  the  next  processor.  However,  if  no  processor 
"claims"  a  frame,  it  will  eventually  make  its  way  around  the  ring  and  return  to  the  originating 
processor;  such  frames  with  a  source  equal  to  the  receiving  processor  do  not  continue  to  be 
forwarded.  In  this  case,  an  error  message  is  printed  to  the  console.  Please  note  that  this 
overview  does  not  describe  Link  layer  error  detection  or  recovery  mechanisms. 

2.6  Comer's  Protocol  -  Data  Link  level 

There  are  two  processes  at  the  Data  Link  level  associated  with  each  port.  However,  input 
port  processing  differs  greatly  from  output  port  processing.  The  difference  in  processing  is  a 
result  of  requests  from  the  Frame  level,  not  in  an  internal  knowledge  of  the  type  of  port 
being  served. 

Each  process  is  a  classical  interrupt-drtven  device  handler.  Comer,  however,  allows  these  to 
be  viewed  as  a  type  of  process  that  "waits"  on  interrupts  when  asked  to  do  so  by  a  Frame 
level  request.  The  input  interrupt  handler  (dlciin)  waits  on  incoming  characters,  receiving 
control  when  a  character  has  arrived.  (Dlcoin),  the  output  interrupt  handler,  waits  for 
outgoing  characters  to  be  transmitted,  receiving  control  when  it's  time  to  send  another 
character.  While  no  appropriate  Frame  level  request  is  active,  any  interrupt  is  ignored. 
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Data  Link  processing  at  the  output  port  is  initiated  by  the  Frame  level  via  a  write  request  to 
dlcoin.  Prior  to  the  mite  request,  a  process  must  be  registered  with  the  ACK  handler 
portion  of  the  associated  dlciin  process  to  receive  the  ACKs,  etc.  sent  to  the  output  port  by 
the  receiving  machine.  The  (dlcoin-write)  process  transmits  a  frame  after  "framing"  its  input 
data  with  the  START  character  at  the  beginning  and  the  EOB  character  at  the  end.  In  order 
to  prevent  these  and  other  protocol-related  "control"  characters  from  appearing  in  the  packet 
portion  of  the  transmitted  frame,  "character-stuffing"  is  performed.  "Control"  characters  in 
the  packet  are  replaced  by  an  ESC  (escape)  character  followed  by  the  "control"  character 
modified  by  zeroing  a  particular  bit.  (All  "control"  characters  have  the  particular  bit  set  to 
one.) 

The  dlciin-ACK  process  will  send  any  characters  received  on  the  output  port  to  the  previously 
registered  ACK-receiving  process,  with  one  exception.  If  the  received  character  is 
RESTART,  dlciin-ACK  checks  the  state  of  the  associated  dlcoin-write  process  by  examining 
a  shared  variable.  If  the  state  is  TNIT"  (implying  dlcoin-write  is  not  currently  transmitting  a 
frame),  the  RESTART  is  sent  to  the  registered  process,  as  before.  If,  however,  the  state  is 
anything  other  than  TNIT,"  dlciin-ACK  will  force  dlcoin-write' s  state  to  "RESTART."  The 
"RESTART"  state  informs  dlcoin-write  to  stop  transmitting  the  current  frame  and  start 
retransmitting  from  the  beginning.  The  RESTART  character  thus  serves  as  a  quick  method 
of  informing  dlcoin-write  that  the  frame  currently  being  transmitted  has  already  been 
rejected,  and  continued  transmission  is  useless. 

Data  Link  processing  at  the  input  port  is  also  initiated  at  the  Frame  level,  via  a  read  request 
to  dlciin.  The  dlciin-read  process  examines  incoming  characters,  looking  for  the  START 
character.    It  then  stores  the  packet  from  the  incoming  frame,  after  "unstuffing"  the  two- 
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character  ESC  sequences  by  setting  the  previously  zeroed  bit  in  the  character  following  ESC. 
The  frame  ends  when  the  input  buffer  fills  or  EOB  is  received.   During  this  processing,  some 

character-related  transmission  faults  can  be  detected.  These  are: 

•  a  hardware-detected  error  (carrier  loss,  framing  error,  data  overrun,  etc.)  and 

•  a  character  with  the  special  "zeroed  bit"  already  set  following  an  ESC. 

Any  such  fault  causes  dlciin-read  to  send  a  RESTART  character  back  to  the  transmitting 
machine.  The  dlciin-ACK  process  would  receive  the  RESTART  and  either  initiate 
retransmission  of  the  frame  (as  described  previously)  or  notify  the  Frame  level  registered 
ACK  process.  The  bit  representation  of  RESTART  has  been  chosen  to  not  overlap  ACK, 
NACK  or  SACK9  responses;  the  output  process  treats  anything  other  than  ACK  or  SACK  as 
a  NACK,  so  the  net  result  of  a  RESTART  is  retransmission  of  the  frame. 

The  Frame  level  sends  ACK,  NACK  or  SACK  responses  to  the  transmitting  machine  using 
the  putc  request.  The  dicoin-putc  process  just  transmits  the  requested  single-character 
response. 

2.7  Comer's  Protocol  —  Frame  level 

There  are  three  processes  at  the  Frame  level.  The  output  Frame  level  process  (/output) 
accepts  data  for  transmission  from  application  processes,  adds  destination  and  sequencing 
information,  sends  the  packet  to  the  output  port  via  (dlcoin-write),  and  retains  a  copy  until 
successfully  acknowledged  by  the  next  machine's  input  Frame  level  process  (finput). 
Unacknowledged  frames  are  also  timed  for  retransmission.    The  finput  process  receives 


9.    SACK  u  a  type  of  NACK  thai  win  alw>  cause  the  expected  srqiirnrr  numbers  at  the  lender  and  receiver  to  be  react  Thin  wis  be 
described  later. 
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frames  from  the  input  port  via  (dlciin-read),  validates  them  and  either  sends  the  frame's  data 
to  the  appropriate  application  process  or  forwards  the  frame  to  the  next  machine  (via  another 
/output  process).  It  also  sends  an  ACK  back  to  the  transmitter  via  dlcoin-piac.  A  third 
process  (ftimer)  provides  the  (output  process  with  the  timeout  indication  needed  to  force 
retransmission  of  an  unacknowledged  frame.  The  ftimer  process  sleeps  unless  such  a  frame 
exists. 

To  detect  invalid  frames,  finput  first  verifies  that  the  number  of  characters  in  the  frame 
matches  the  length  field  within  the  frame.  Missing  or  out-of-order  frames  are  detected  by 
assigning  a  sequence  number  to  each  frame  when  it  is  received  from  an  application  process. 
Comer's  protocol  uses  a  3-bit  sequence  number  in  each  frame  to  detect  missing  or  out-of- 
order  frames;  each  new  frame  is  assigned  an  incremented  sequence  number  (modulo  8). 
After  sending  a  frame  (via  dlcoin-write),  /output  waits  tor  finput  (in  the  receiving  machine) 
to  acknowledge  the  frame;  this  is  commonly  known  as  a  stop-and-wait  ARO  (Automatic 
Repeat  Request)  technique.  Failure  to  receive  an  acknowledgement  will  be  detected  by  the 
ftimer  process  and  the  unacknowledged  frame  will  be  retransmitted. 

When  finput  receives  a  frame,  the  sequence  number  is  compared  to  the  expected  sequence 
number.  If  they  match,  an  ACK  "character"  with  the  "next  expected"  sequence  number 
embedded  is  sent  back  to  the  transmitter.  If  the  ACK  is  successfully  received  by  the 
transmitting  /output  process  and  the  embedded  sequence  number  matches  the  next  expected 
sequence  number,  the  unacknowledged  frame  is  removed  from  /output's  buffers  and  the 
ftimer  process  is  put  to  sleep.  If  the  received  frame's  sequence  number  doesn't  match,  a 
NACK  "character"  (with  the  current  expected  sequence  number  embedded)  is  sent  to  the 
transmitter.    The  transmitting  /output  process  will  retransmit  the  unacknowledged  frame 
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(without  examining  the  NACK's  expected  sequence  number)  and  wait  for  a  response  (ACK 
or  NACK  or  SACK). 

The  transmitting  and  receiving  ends  of  the  link  could  get  out  of  sync  with  regard  to  sequence 
numbers.  V /input's  expected  frame  number  is  4  and  the  message  sitting  in  /output's  buffer  is 
3  (or  anything  other  than  4),  then  sending  NACKs  back  to  the  /output  process  will  never 
(without  some  improbable  bit  mutilation)  result  in  a  message  with  a  sequence  number  of  4 
being  retransmitted.  To  "solve"  this  problem,  the  /input  process  will  send  a  SACK  (in  place 
of  a  NACK)  if  sequence  number  mismatches  cause  more  than  two  NACKs  on  the  same 
incoming  message. 

SACK  informs  the  /output  process  to  reset  it's  current  sequence  number  back  to  0;finput  also 
resets  its  expected  sequence  number.  Sequence  number  0  will  now  be  used  to  re-transmit  the 
unacknowledged  message  and  that  number  will  be  acceptable  to  the  /input  process.  Note  that 
the  above  scenario  is  not  that  improbable;  if  the  ACK  for  frame  3  was  lost,  /output  will 
time-out  and  retransmit  frame  3.  However,  /input  will  be  willing  to  accept  frame  4  only  and 
will  respond  with  a  NACK.  If  this  occurred,  /input  would  eventually  accept  the  data  in 
frame  3  twice10,  once  as  frame  3  (normally)  and  again  as  the  new  frame  0  (after  NACKing 
three  times). 

Comer's  protocol  allows  a  single  message  to  be  transmitted  to  all  machines  on  the  ring 
network;  this  is  known  as  a  broadcast  message.  One  particular  value  (zero)  in  the 
destination  field  of  the  frame  header  implies  that  the  frame  should  both  be  passed  up  to  the 


10.  Comer  met  that  dejection  of  duplicate  meaaagea  must  be  it  •  layer  above  the  Frame  level    The  detection  a 
rdy  on  the  Frame  aaaajajfla  number* 
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application's  distribution  process  and  forwarded  to  the  next  machine.  When  the  frame  has 
been  forwarded  completely  around  the  ring,  the  originator  of  the  broadcast  message  stops 
forwarding  the  frame. 

Aside  from  the  duplicate  message  problem  and  the  lack  of  any  rigorous  bit  mutilation 
detection,  Comer's  data  link  protocol  appears  to  perform  well.  However,  there  are  several 
extensions  that  would  enhance  it's  efficiency  and  robustness,  as  well  as  adapt  it  for  use  in  a 
non-ring  network.  All  this  is  the  subject  of  the  following  chapter. 
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3.   PROTOCOL  DESIGN 

There  are  several  problems  with  Comer's  protocol  (see  below)  which  make  it  unsuitable  for 
many  applications.  This  chapter  will  describe  possible  extensions  to  the  protocol  and  choose 
a  subset  of  those  extensions  for  further  discussion.  The  resulting  extended  protocol  will  be 
described  in  detail,  both  in  text  and  in  modified  state  transition  diagrams.  Several  scenarios 
will  then  be  presented  that  show  its  operation  under  normal  and  failure  conditions. 

Two  types  of  extensions  to  Comer's  protocol  are  possible;  those  that  add  new  capabilities 
(features)  to  improve  efficiency,  control,  and  flexibility  (allowing  alternate  applications  and 
architectures)  and  those  that  repair  problems  in  the  existing  protocol.  Note  that  while  no 
formal  verification  of  Comer's  protocol  was  performed,  examination  of  both  the  English 
description  and  the  program  code  revealed  several  problems  with  the  protocol.    These 

include: 

•  no  checksum  over  any  portion  of  the  frame, 

•  the  possibility  of  passing  duplicate  packets  to  the  Network  layer, 

•  failure  to  detect  excessively  long  frames  and 

•  failure  to  detect  a  non-working  link. 

3.1  Possible  Extensions 

Any  checksum  mechanism  could  improve  the  ability  of  the  protocol  to  withstand  transmission 
errors.  It  is  unusual  to  find  any  protocol  that  does  not  use  at  least  a  simple  exclusive-or  or 
sum-of-the-characters  checksum. 

Duplicate  packets  may  be  prevented  by  enhancing  the  NACK  mechanism  and  removing  the 
SACK  acknowledgement.  The  detection  of  a  long  frame  is  a  simple  change;  receiving  a 
non-EOB  character  after  the  frame  buffer  is  full  would  force  the  frame  to  be  treated  as 
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invalid.  (Comer's  implementation  assumed  an  EOB  would  follow  and  passed  the  frame  up 
to  the  Frame  level.) 

Another  extension  could  be  the  addition  of  a  heartbeat  frame;  it  is  periodically  transmitted  in 
the  absence  of  other  outgoing  frames.  Trie  receiving  process  would  complain  if  no  incoming 
frames  were  detected  over  several  heartbeat  intervals.  This  would  detect  link  failures  (or 
lockup  at  the  other  end)  even  in  the  absence  of  outgoing  traffic. 

One  capability  that  could  add  flexibility  is  operation  on  non-ring  architectures.  This  would 
require  that  frames  be  passed  to  a  "routing"  process  at  the  Network  layer.  This  process 
would  deliver  frames  after  examining  their  destination  and  allow  the  output  link  for  that 
destination  to  change  over  time. 

A  further  extension  could  allow  full-duplex  transmission  of  frames  over  a  link.  Major 
changes  to  the  single-character  ACK/NACK/SACK  mechanism  would  be  required.  Also, 
the  Data  Link  input  process  must  allow  frames  and  acknowledgements  to  travel  in  both 
directions  on  a  link. 

Further  flexibility  could  be  provided  by  offering  virtual  circuit  facilities  at  the  Link  layer,  as 
proposed  in  [IEE84].  This  would  require  (at  least)  the  addition  of  another  sublayer  within 
the  Link  layer. 

A  related  extension  could  be  the  provision  of  datagram  facilities.  This  would  allow  a  packet 
to  be  transmitted  without  retransmission  or  sequencing  control.  Errors  in  such  packets  would 
force  them  to  be  discarded  without  indication  to  either  the  originating  or  transmitting  node. 

A  final  extension  for  flexibility  could  add  unbalanced  mode  operation  to  the  protocol,  in  the 
spirit  of  HDLC.    Several  versions  of  link  Control  (master,  slave,  etc.)   would  have  to  be 
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added,  as  well  as  a  means  for  nodes  to  mutually  agree  on  a  version  to  use  over  a  period  of 
time.  One  could  even  imagine  adding  the  ability  to  operate  in  a  multi-point  configuration 
(i.e.,  a  master  and  several  slave  nodes  connected  to  the  same  link),  although  this  would 
require  changes  to  the  (assumed)  RS-232C  Physical  layer. 

A  control  extension  could  provide  the  ability  to  stop  (and  start)  traffic  over  a  link  without 
loss  of  frames.  This  would  allow  a  user-level  process  to  request  that  the  link  be  logically 
"disconnected"  after  ensuring  that  all  preceding  frames  had  been  transmitted.  All  further 
requests  for  packet  transfer  from  the  user  lever  would  be  blocked,  but  a  request  to  reconnect 
the  link  would  be  allowed  from  either  end  of  the  link.  Such  a  mechanism  must  ensure  that 
neither  end  of  a  link  is  "disconnected"  when  the  other  end  is  "connected." 

Another  control  extension  could  allow  direct  control  and  monitoring  of  the  Link  layer  via 
user  "Link  control"  messages.  This  would  allow  a  user-level  process  to  retrieve  the  status  of 
the  Link  layer  of  a  given  link  from  any  node,  providing  a  method  for  collecting  statistics  on 
performance  from  a  central  location.  It  could  also  allow  a  remote  node  to  "connect"  or 
"disconnect"  the  link,  as  well  as  simulate  packet  input  to  the  Link  layer.  If  a  "download 
protocol"  capability  also  existed,  it  would  be  possible  to  load  new  protocols  (of  any  layer) 
into  the  node  from  remote  locations.  Collectively,  these  capabilities  would  allow  unattended 
operation  of  some  nodes  of  the  network. 

Pipelining  of  frames  and  piggybacking  of  acknowledgements  are  obvious  efficiency 
extensions.  With  pipelining  comes  the  choice  of  various  possible  retransmission  strategies 
such  as  "Go-Back-N"  or  "selective  repeat."  Pipelining  would  make  the  SACK 
^synchronization  mechanism  even  worse  since  it  could  cause  several  duplicate  frames  to  be 
1  to  the  Network  layer.  The  effectiveness  of  Comer's  RESTART  mechanism  could  be 
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affected  by  the  particular  implementation  chosen11.  Piggybacking,  to  be  effective,  would 
require  that  a  few  ACKs  be  postponed  for  a  short  period  waiting  for  packets  in  the  reverse 
direction. 

3.2  Choice  of  Extensions 

The  following  set  of  extensions  has  been  chosen  for  use  in  the  remainder  of  this  paper. 

Where  necessary,  the  reason  for  choosing  that  extension  is  discussed. 

•  Checksums  are  added  to  all  frames,  via  the  CRC-16  technique. 

•  Duplicate  frames  are  never  passed  to  the  Network  or  user  levels.  The  SACK 
acknowledgement  is  dropped.  Both  ACK  and  NACK  will  carry  the  sequence  number 
indicating  the  last  frame  received  in  sequence. 

•  Excessively  long  frames  are  detected  and  treated  as  "damaged"  frames.  It  is  unlikely 
that  such  frames  would  survive  the  checksum  mechanism  (approximately  one  chance 
in  2    ),  but  this  extension  is  almost  trivial. 

•  The  heartbeat  capability  is  added. 

•  Various  network  architectures  are  supported,  although  this  is  achieved  primarily  by 
inventing  a  routing  process  in  the  Network  layer.  The  method  by  which  the  routing 
process  performs  its  task  is  beyond  the  scope  of  this  paper,  however12. 

•  Full-duplex  transmission  of  packets  and  acknowledgements  is  added.  The 
acknowledgement  and  control  "characters"  from  Comer  must  be  converted  into 
control  frames  and  distinguished  from  frames  bearing  packets. 

•  A  "connect"  and  "disconnect"  control  facility  is  provided.  The  link  is  thus  in  either  a 
"running"  or  "disconnected"  state.  User  /send  requests  and  forwarded  packets  are 
denied  in  the  "disconnected"  state  and  the  heartbeat  mechanism  is  disabled.  Incoming 
frames  other  than  those  associated  with  link  control  are  discarded,  with  an  AMDISC 
control  frame  being  sent  back  to  the  transmitter. 

•  Pipelining  is  added  to  allow  more  efficient  use  of  the  physical  link.  The 
"Go-Back-N"  retransmission  strategy  is  chosen  for  both  its  effectiveness   and 


11.  RESTART  ones  the  current  Data  link  output  transmission  to  abort-  In  Comer's  protocol,  tub  allowed  retransmission  of  the 
current  frame  to  begin  immediately  With  pipelining,  the  frame  containing  the  error  may  not  be  the  one  being  transmitted.  If  the 
retransmission  strategy  allows  frames  to  arrive  out  of  order,  as  in  "selective  repeat,"  then  Utile  would  be  gained  in  atoning 
transmission  of  a  frame  that  was  probably  on  its  way  to  being  accepted. 

12.  While  this  extension  removes  a  capability  from  the  original  protocol  ( explicit  forwarding  of  frames),  note  that  Corner's  rooting  at 
the  Link  layer  was  possible  only  because  of  the  architecture  However,  rooting  "off  the  network"  via  gateways  was  mentioned  as  a 
Network  layer  task  in  [Comg4].  His  total  description  of  the  routine;  process  was  that  it "...  computes  a  new  route  for  the  packet 
..."  1  am  thus  following  (at  least  here)  in  Comer's  footsteps. 
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simplicity.  Comer's  RESTART  mechanism  will  be  only  partially  used.  A  means  will 
be  provided  to  abort  any  current  frame  transmission  when  frame  retransmission  is 
needed.  Retransmission  will  be  initiated  at  the  Frame  level.  No  use  will  be  made  of 
a  RESTART  character. 

•  Piggybacking  of  positive  acknowledgements  is  added. 

In  choosing  the  particular  extensions  to  make  to  Comer's  protocol,  the  goal  was  to  provide  a 
non-trivial  set  of  extensions  without  attempting  to  do  everything  mentioned  above.  The 
extensions  listed  above  are  certainly  non-trivial.  They  entail  changes  to  all  areas  of  Comer's 
protocol,  and  also  alter  the  interfaces  to  the  adjacent  layers. 

33  Interfaces  to  Other  Layers 

Comer's  Network  layer  could  make  only  two  requests  of  the  Link  layer  for  a  given  link, 
fsend  and  /receive.  The  extended  protocol  recognizes  a  third  request,  fctrl,  to  either  establish 
the  link  connection  or  to  disconnect  the  link.  For  a  given  link,  a  single  process  is  still 
identified  to  receive  all  incoming  messages  (packets  destined  for  this  node).  This  process  is 
responsible  for  distributing  the  messages  to  the  proper  applications. 

The  extensions  require  the  addition  of  a  routing  process  to  the  Network  layer.  Any  accepted 
incoming  frames  are  passed  to  this  process.  The  Network  layer  sends  outgoing  packets  to  the 
Link  layer  for  transmission;  these  have  a  priority  indication  so  that,  for  example,  forwarded 
packets  may  be  transmitted  before  fsend  packets  that  have  not  yet  been  transmitted. 

No  major  changes  in  the  interface  to  the  Physical  layer  were  required  by  the  extensions.  The 
full-duplex  transmission  capability  of  the  layer  is  now  being  fully  utilized.  Both  input  and 
output  continue  to  be  viewed  as  a  stream  of  characters.  The  single  character  ACK  and 
NACK  can  no  longer  be  used,  since  they  could  be  confused  with  extraneous  characters 
between  frames;  they  also  can  benefit  from  the  use  of  a  checksum. 
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3.4  Protocol  Overview 

To  simplify  the  presentation  of  the  overall  data  link  protocol,  it  has  been  divided  into  four 
sublayers  [Boc79].  These  correspond  (almost)  to  the  basic  functions  of  character-oriented 
Link  layer  protocols  listed  in  the  previous  chapter.  These  sublayers  are  (from  lowest  level  to 

highest): 

•  Framing  and  Transparency  -  determining  the  actual  characters  sent  over  the  physical 
link, 

•  Error  Detection  -  validating  the  incoming  frame, 

•  Data  Transfer  -  controlling  the  sequencing  of  frames,  the  transmission  of  ACKs  and 
NACKs,  and  maintaining  frame  ordering  and 

•  Link  Control  -  controlling  the  state  of  the  link  and  handling  requests  for  connect  and 
disconnect. 

Each  sublayer  can  be  viewed  as  having  its  own  protocol  for  communicating  with  peer 
sublayers  in  other  entities.  However,  the  boundary  between  sublayers  is  not  as  firm  as 
between  layers.  For  example,  the  sublayers  can  act  together  via  shared  variables  to 
accomplish  their  task.  This  will  be  further  explained  in  the  descriptions  of  the  protocol 
sublayers. 

Each  of  the  sublayer  protocols  will  be  described  in  text  and  some  will  be  described  by 
modified  transition  diagrams  [BocfSO].  These  diagrams  are  an  extension  of  the  state  transition 
diagram  and  allow  transitions  to  manipulate  variables  via  actions  described  in  fragments  of 
program  code.  Transitions  are  labeled  and  typically  identified  further  as  output  transitions 
(underlined)  or  as  non-output  transitions  (not  underlined).  A  table  links  a  transition  label 
with  the  program  code  fragment.  Associated  with  each  transition  (in  the  table)  is  an 
enabling  predicate;  the  transition  may  be  taken  only  if  the  predicate  is  true.  If  multiple 
transition  predicates  are  true,  the  transition  taken  is  randomly  chosen;  however,  a  rule  for 
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arbitrating  the  decision  can  be  specified.  In  addition,  diagrams  may  be  hierarchically 
dependent  on  other  (higher  level)  diagrams.  For  example,  the  Data  Transfer  protocol  is 
dependent  on  the  state  of  the  Link  Control  protocol,  since  Data  Transfer  only  applies  in  the 
"connected"  and  "waiting_DISC  states. 

To  aid  in  understanding  the  protocol  descriptions,  an  overview  of  the  protocol  layers  and  the 
sublayers  within  the  Link  layer  appears  on  the  next  page.  This  is  followed  by  a  figure 
showing  frame  layout,  "control"  character  assignments  and  types  of  frames. 
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Figure  2.     Design  Protocol  -  Overview  and  Sublayers 
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seq 

ack 

len 

from 

to 

net -type 

data  |  MAXmsg  ] 

Header m- 


-  Packet  ■ 


seq      =    Information  Frame  ( values  '0'  to  '0'  +  MaxSeq) 

or   Control  Frame  (values  '0'  +  MaxSeq  + 1  to  255  decimal)  [See  Below] 

ack      =    Piggy-backed  Acknowledgement  (values '0' to '0'  + MaxSeq) 

len      =  length  of  Frame  (in  character  units)  [  3  or  more  for  Control  Frames  ] 

[  6  or  more  for  Information  Frames] 

from     =   ID  of  frame  originator 

to  =  ID  of  intended  destination  (  0  implies  'broadcast  frame" ) 
nettype  =  Network  Level  Information  ( type  of  data  in  Packet,  etc. ) 
data    =  0  to  MAXmsg  characters  of  Packet  data 

transmission  direction 


Frame  in  Transmission 


SOH 

Frame  with  ESCaped  characters 

ESCaped  Checksum 

EOB 

SOH  =  0253,  EOB  =  0252,  ESC  =  0251   (octal) 
Checksum  =  CCITT  standard  CRC  calculation  over  non- ESCaped  Frame 


Frame  Types         I  Control  Frame  character  IDs  in  () ) 

*  INFO  Information  Frame  (  contains  Packet  as  above  ) 

ACK  (A)  Explicit  Acknowledgement  Frame 

[sent  only  if  no  reverse  INFO  traffic  J 

NACK  (N)        Negative  Acknowledgement 

[sent  on  first  bad  frame  in  a  sequence  of  bad  frames  ] 

HEAR(H)        Heartbeat  [sent  occasionally  if  no  other  traffic  ] 

*  START  (S)       Start  Connection  [  "ack"  unused  ] 


Data  Transfer 
}  (only  valid 
if  Link  is  up) 


STACK  (T)       Connection  Acknowledgement 

[  "from"  contains  next  valid  INFO  "seq"  value  ] 


> 


Link  Control 
Frames 


DISC  (D)         Request  Disconnetc 

AMDISC  (M)    Disconnect  Complete  [  "ack"  unused  ] 

"*"  indicates  Frame  Types  that  are  timed  and  retransmitted  if  unacknowledged. 


Figure  3.    Frame  types  and  layout 


•30- 


3.5  Framing  and  Transparency  Sublayer 

The  Framing  sublayer  operates  almost  identically  to  Comer's  Data  Link  level  processes.  The 
only  major  changes  are  the  addition  of  a  checksum  just  before  the  transmission  of  EOB  and 
the  elimination  of  the  RESTART  "control"  character.  The  modified  transition  diagrams  for 
both  the  input  and  output  portions  of  the  Framing  and  Transparency  protocol  appear  in  the 
next  two  figures. 

Note  that  a  RESTART  "control"  character  is  not  transmitted  in  the  extended  protocol. 
Errors  that  would  have  resulted  in  RESTART  will  now  generate  a  NACK.  However,  a 
related  mechanism  is  implemented  using  a  global  variable  C_restart.  The  Data  Transfer 
sublayer  sets  G_restart  only  when  beginning  to  retransmit  a  series  of  frames.  The  Framing 
sublayer  will  stop  transmission  of  the  current  frame  (if  any)  if  G_reslart  is  set.  Framing  will 
also  reset  Gjrestart.  This  allows  any  transmission  to  be  stopped  immediately,  rather  than 
waiting  for  it  to  complete,  so  that  the  retransmission  can  begin  sooner. 

As  an  example  of  this  protocol: 

< transmission  direction 

Header, A, B, ESC, F.SOH  : original  Frame  characters 

SOH, Header, A, B, ESC, [ESC1.F, ESC, [SOH],cksum, EOB      :as  transmitted 
Header, A, B, ESC, F.SOH.oksum  : passed  to  Error  Detection 

where  [bracketed]  characters  represent  the  original  characters  with  bit  7  set  to  zero. 


non-SOH 


SOH  or  £ 


Global 

Grestart  -  set  by  foutputQ 
Initial  State 

Ready 
Variables  and  Functions 

count :  int 

but  [MAXfr] :  char  array 

ch :  char 

send(X) 

readCHO 
unesc(ch) 


number  of  characters  stored  in  "buf' 
buffer  to  hold  result  frame 
holds  last  character  read 
send  frame  or  error  status 

to  Error  Detection  sub  -  layer 
reads  next  character  from  Physical  Layer 
returns  character  to  substitued  for  "ch"  when 

following  ESC  on  input  (returns  - 1  on  error) 


Note:  Prior  to  testing  for  the  Transition,  an  implied  "ch  =  readCHO"  is  executed. 
If  multiple  Enabling  Predicates  are  true,  the  first  listed  Transition  is  used. 
The  notation  "[oldState  >  newState)"  indicates  State  Transition  from  diagram  above. 


Transition        Enabling  Pred, 

Acton 

Meaning 

SOH 

ch==SOH 

count  =  0 

Start  processing  chars. 

("any"  >  Read] 

non-SOH 

chl=  SOH 

- 

Wait  for  it! 

[Ready] 

EOB 

ch==EOB 

send(buf) 

Send  frame  up 

[Read  >  Ready] 

EC 

ch  =  =  ESC 

- 

Saw  ESC 

[Read  >  Escape] 

£ 

l{SOH,EOB,ESC) 

buf  [count  +  +  ]  =  ch 

Store  ch 

[Read] 

&&count<  =bufsize 

Overflow 

count  >  bufsize 

send("error2") 

Indicate  frame  TOO 

("any"  >  Ready] 

LARGE 

EI 

unesc(ch)>  =0 

buf  [count  +  +  ]  = 

Store  un  -  escaped 

[Escape  >  Read] 

unesc(ch) 

character 

bad-ET 

unesc(ch)<0 

sendferrorl") 

Indicate  BAD  char. 

[Escape  >  Ready] 

was  found 

Figure  4.     Framing  and  Transparency  (Input) 
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Global 

G  restart 

-  setbyfadput 

Initial  State 

Idle,  fr  = 

framereqO,  G_restart  =  false 

Variables  and  Functions 

fr:  frame 

pointer 

address  of  frame  to  transmit 

frcount:  i 

nteger 

number  of  frame  characters 
remaining  to  transmit 

cksum[2] 

:  char 

holds  checksum  in  character  form 

ch:  char 

holds  character  from  the  frame 

next() 

returns  next  character  from  frame 

escape  (x) 

true  if  x  should  be  escaped 

escapec(c) 

replacement  character  for  c  when  escaped 

framereqO 

returns  address  of  frame  to  send 

crc(fr,  count) 

returns  CCm  CRC  checksum 

Transitions 

Enabling  Pred. 

Action 

Meaning 

framereq 

framereqO 

frcount  =  fr 

.length 

Start  sending  frame 

[idle>Writel 

completes, 
returning  char. 

cksum  =  crc 
write  SOH 
ch  =  next() 

(fr.frcount) 

£ 

frcount  >  0  && 

write  ch 

Transmit  character 

[Write] 

IGrestart  && 
lescape(ch) 

ch  =  nextO 
frcount  — 

EC 

frcount  >  0  && 

write  ESC 

Transmit  character 

IWrite] 

IGrestart  && 

ch  =  escapec(ch) 

requiring  ESC  processing 

escape(ch) 

write  ch 
ch  =  next() 
frcount  — 

G- restart 

Grestart  true 

release  fr 

Stop  early 

[Write  >  idle) 

empty 

frcount  <  =  0 

if(  escape(ch  =  cksum(1J)) 

Finish  sending  frame 

[Write  >  idle] 

write  ESC 

ch = escapec(ch) 
write  ch 

[..  repeat  for  cksum[2]] 
write  EOB 
release  EOB 


Figure  5.     Framing  and  Transparency  (Output) 
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3.6  Error  Detection  Sublayer 

The  error  detection  sublayer  is  responsible  for  handling  errors  reported  by  the  Framing  and 
Transparency  (input)  sublayer  and  for  detecting  any  other  errors  in  the  frame.  This  protocol 
does  nothing  to  output,  since  the  Frame  and  Transparency  sublayer  computes  and  sends  the 
checksum.  In  effect,  Error  Detection  provides  a  function  called  send  that  is  called  by  the 
Framing  and  Transparency  sublayer.  A  function  called  sendon  is  then  used  by  Error 
Detection  to  pass  frame  and  error  indications  up  to  the  Data  Transfer  sublayer.  The 
pseudo-code  for  the  send  function  is  shown  in  the  figure  below. 


send (fr, count, status)       fr-frame  address 

count =no.  non-ESC  characters  read 

between  SOH  and  EOB. 
status=0  unless  error 

detected  by  Framing  sublayer. 
{ 

if  (status  1=0)  { 

sendon ( status ) ;    pass  error  to  Data  Transfer 
return; 
} 

count  ■  count  -  2;  remove  checksum  from  frame 

if  (  count  <  MINfr  )  { 

sendon  ( 4 ) ;      frame  too  short 
return ; 
> 
if  (  count  1=  fr.len  )  { 

sendon(S);      count  incorrect 
return; 
} 

if  (  crclfr,  fr.len)  1-  checksum  at  end  of  frame)  { 
sendon(6);      bad  checksum 
return ; 
} 
sendon(fr);  send  good  frame  to  Data  Transfer 


Figure  6.  Error  Detection  Diagram 
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3.7  Data  Transfer  Sublayer 

This  sublayer  implements  the  sequencing  checks  that  ensure  correct  (in-order)  delivery  of 
packets  to  the  Network  layer.  It  implements  a  seven  frame  sending  window  and  a  single 
frame  receive  window.  The  "Go— Back-N"  retransmission  strategy  is  used.  Operation  of 
the  Data  Transfer  sublayer  occurs  only  when  the  LinkState  (in  Link  Control)  is  "connected" 
or  "waiting_DISC." 

Four  variables  control  the  action  of  the  protocol: 

•  ExpectedF  -  this  is  the  sequence  number  of  the  next  frame  that  can  be  acknowledged 
and  sent  up  to  a  higher  level, 

•  ExpectedA  -  this  is  the  sequence  number  of  the  oldest  unacknowledged  frame  (if  any) 
waiting  for  acknowledgement, 

•  NextF  -  the  sequence  number  to  be  associated  with  the  next  frame  sent  over  the  link 
and 

•  NoNack  -  a  boolean  that  allows  a  NACK  response  if  true. 

In  general,  ExpectedF  is  incremented  when  a  frame  is  sent  up  to  a  higher  level.  ExpectedA 
is  incremented  for  each  unacknowledged  frame  that  is  acknowledged  by  an  incoming  ACK. 
NextF  is  incremented  each  time  a  frame  is  added  to  the  unacknowledged  send  window  (up  to 
7  outstanding).  NextF  is  set  to  ExpectedA  to  begin  a  "Go-Back-N"  retransmission,  and 
the  Gjrestart  global  variable  is  set.  NoNack  is  initially  true,  becomes  false  if  a  NACK  is 
sent  and  then  becomes  true  when  the  ExpectedF  frame  is  finally  accepted.  (Only  one  NACK 
is  sent  on  an  error  for  a  particular  value  of  ExpectedF,  to  avoid  swamping  the  link  with  long 
series  of  NACKs  if  long  series  of  out-of-sequence  frames  are  being  received.) 

This  strategy  of  avoiding  redundant  NACKs  has  an  unfortunate  failure  mode13.    While 
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unlikely,  the  failure  "stalls"  the  protocol  until  some  reverse  traffic  (to  the  transmitter)  tells  the 
transmitter  the  last  frame  received  in  sequence  (via  the  piggyback  ACK).  To  "fix"  the  failure 
without  reverse  traffic,  the  HEARtbeat  frame  (essentially  internal  traffic)  is  transmitted  if  no 
reverse  traffic  appears  in  a  defined  interval. 

In  order  to  effectively  use  the  piggyback  ACK,  the  explicit  ACK  frame  is  delayed  for  up  to 
three  incoming  frames  (or  a  short  traffic-less  interval).  Any  outgoing  traffic  during  the  delay 
will  cancel  the  explicit  ACK. 


13.  The  scenario  leading  to  this  state  is  described  in  the  Data  Transfer  Failure  Scenarios  figure  later  in  tins  chapter.  The  problem 
occurs  only  when  there  is  no  traffic  in  either  direction  other  than  the  frame  being  retransmitted.  Two  failures  are  also  required  to 
force  this  condition,  the  loss  of  the  ACK  sent  when  the  frame  was  originally  correctly  received  and  the  loss  of  the  SACK  returned 
the  first  time  the  frame  was  re-received. 
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No  State  Diagram  --  just  reacts  to  incoming  frames 

and  requests  to  send  new  Packets . 
Globals 
LinkState: {DISC, waiting  DISC, CONN, waiting_CONN} 

irom  Link  Control 
ExpectedF: Seq  next  incoming  frame  expected 
ExpectedA: Seq  next  acknowledgement  expected 
NextF: Seq      next  seq.  number  for  outgoing  frame 
buffered       total  frames  buffered  in  Data  Transfer 
(Variables  of  type  Seq  use  modulo  N  arithmetic) 
(  N  =  a  small  integer,  typically  a  power  of  2) 

Variables  and  Functions 
windowed       frames  currently  in  window  (max.  Nwindowed) 
DoNack:bool    true  initially  and  when  good  ACK  arrives. 

false  if  ExpectedF  already  NACKed  once 
FR  type  of  Frame  Received  {INFO, ACK, NACK, HEAR} 

send ( type, num)  adds  "type"  frame  to  Transmit  Queue  with 
ack  =  (ExpectedF-1).   If  INFO,  num  = 
frame  number  in  window.   Starts  frame  timer 
and  ACK  timer.   Sets  "lastACK"  to  (ExpectedF-1). 
between(x,y,z)  true  if  x<=y<z,  modulo  seq.  numbers. 
sendup( )       sends  packet  in  current  frame  to  Network  Layer. 

The  following  only  operate  when  LinkState={CONN,waiting_DISC} 

Frame  or  event  Action  when  frame  received 


INFO, seq, ack:  if  (seq  -"  ExpectedF)  { 

sendup();    /*  Frame  to  higher  layer  */ 
ExpectedF  ++; 
DoNack  =  true; 

> 

else  if  (seq  1=  ExpectedF  &&  DoNack)  { 

send(NACK,0);    /*  Send  NACK  if  1st  time  */ 

DoNack  =  false; 

/*  The  following  segment  is  referred  to  as  HANDLE  ACK  below  */ 
while  between (ExpectedA, ack, NextF)  { 
remove  frame  from  window 
buffered  — ; 
windowed  — ; 
ExpectedA  ++; 

stop  timer  for  frame,  start  ACK  timer 
add  new  frame  to  window  from  Request  Queue, 
if  Request  Queue  not  empty, 

move  from  Request  Queue  to  window 

send (INFO, NextF) 

NextF++; 

/*  End  segment  called  HANDLE  ACK  */ 
ACK:         [  HANDLE  ACK  as  above  ] 


Figure  7.   Data  Transfer  Diagram  (Part  I) 
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NACK: 


HEAR,ack: 
FrameTimeout : 

ACKtimeout: 

HEARtimeout: 
fwdmsg: 


while  between(ExpectedA,ack,NextF)  { 
remove  frame  from  window 
buffered  — ; 
windowed  — ; 
ExpectedA  ++; 
stop  timer  for  frame 
if  Request  Queue  not  empty, 

move  from  Request  Queue  to  window 


> 


NextF++;   /*  DON'T  send( )  yetl 


»/ 


/*  Start  retransmission  here  */ 
for  (  i=ExpectedA;  i  <  NextF;  i++  )  { 

send( INFO, i) ; 
> 

[  HANDLE  ACK  as  on  previous  Figure  ] 
/*  Currently  acts  just  like  ACK  */ 

/*  Start  retransmission  here  */ 
for  (  i=ExpectedA;  i  <  NextF;  i++  )  < 

send(INFO,i) ; 
} 

/*  Slow  outgoing  traffic,  ACK  if  needed 
if  (lastACK  1=  ExpectedF-1) 
send(ACK,0); 

/*  No  outgoing  traffic,  send  HEAR  */ 
send(HEAR,0) 


/*  Transmit  Packet  for  higher  layer  */ 
(Allowed  only  if  buf fered+priority  <  MAXbuffered) 
if  (windowed  <  Nwindowed)  { 

add  frame  to  window  and  send( INFO,Nextf ) 
NextF++; 
windowed  ++ ; 
} 

else  { 
dd 

> 

buf fered++; 


add  frame  to  Request  Queue 


HEARfail: 


/*  Bad  Frame  received  */ 
if  (DoNack)  send ( NACK , 0 ) ; 
DoNack  =  false; 

/*  Failure  to  receive  HEARtbeat  */ 
Print  failure  message 


Figure  8.   Data  Transfer  Diagram  (Part  II) 


■38- 


3.8  Link  Control  Sublayer 

Link  Control  allows  the  user  or  other  end  of  the  link  to  request  that  the  link  be  placed  into 
the  "connected"  or  "disconnected"  state.  On  connect  requests,  the  connection  is  attempted 
MAXattempts  times  before  giving  up  and  reporting  the  problem.  The  connection  will 
synchronize  properly  the  sequence  numbers  expected  at  each  end  of  the  link.  A  connect 
request  from  the  link  to  an  already  connected  link  is  assumed  to  be  from  a  node  that 
"crashed."  The  protocol  will  resequence  the  sequence  numbers  such  that  any 
unacknowledged  frames  in  the  "connected"  node  will  be  accepted  by  the  requesting  node. 
The  requesting  node  is  required  to  begin  its  sequencing  at  0,  but  then  a  "crashed"  node 
probably  lost  any  unacknowledged  frames  anyway.  User  requests  to  send  or  receive  packets 
over  a  "disconnected"  link  will  be  refused. 

Disconnect  requests  can  originate  either  from  the  user  or  over  the  link.  The  timeout  interval 
is  fairly  long,  because  the  AMDISC  acknowledgement  is  not  sent  until  all  unacknowledged 
frames  have  been  acknowledged.  Disconnect  requests  have  a  sequencing  problem  also.  It  is 
possible  for  an  unacknowledged  frame  to  be  retransmitted  many  times  without  an  ACK  or 
NACK  being  returned14.  If  disconnect  had  to  wait  until  this  'lost"  frame  was  acknowledged, 
a  user  would  be  waiting  a  long  time  for  the  request  to  complete  on  what  should  be  an  idle 
link!  To  prevent  the  long  waiting  time,  an  ack  field  appears  in  the  DISC  frame  to  explicitly 
acknowledge  such  frames.  (The  HEARtbeat  frame  would  eventually  cure  this  problem, 
since  it  also  explicitly  acknowledges  the  last  frame  received  in  sequence.) 

14.  This  »  described  in  the  Data  Transfer  section  as  a  justification  for  the  HEARtbeat  frame. 


AMDISC 


timeouts 


STARTL 


STARTC 
STACK 
Globals 

ExpectedA,  ExpectedF 

LinkState,  NextF 

buffered 

{all  Global  to  Data  Transfer  sub  -  layer} 
Initial  State 

DISC 

NextF,  ExpectedF,  ExpectedA,  buffered  =  0 
Variables 

attempts  :  integer  counts  START  or  DISC  frames  sent 

FR  :  frametype  type  of  Frame  received 

receivedDISC  :  {true.false.waiting) 


Note:  Enabling  Predicates  are  tested  in  the  order  listed.  Testing  occurs  only  after  an 
event  has  occurred.  Events  are  "new  Frame  received"  (causing  FR  to  be  set), 
"user  transactions",  and  "timeouts"  of  various  types.  Portions  of  Predicates  referring  to 
the  FR  variable  apply  only  if  the  event  causing  evaluation  was  "new  Frame  received." 


Transition 

START 


Enabling  Pred. 


Action 


[DISC>  fcontrol(CONN) 

wardngCONN] 


user  transaction        LinkState  =waiting_CONN 


attempts  =  0 
start  STARTtimer 
ExpectedA,  NextF  =  0 
ExpectedF  =  0  < 

send  START 


Meaning 
CONN  from  user, 
attempt  CONN. 


altered  by  later  STACK? 


STARTL 
["any"  >  CONN] 


FR==  START 


LinkState  =  CONN 
ExpectedF =0 

stop  STARTtj'me  &  DISCtimer 
send  STACK(ExpectedA) 


Figure  9.     Link  Control  Diagram  (Part  I) 


CONN  from  Link, 
force  CONN, 
Data  Transfer  will 
retransmit  window 
(if  not  empty) 


STACK 

[waiting  CONN> 
CONN] 

FR==STACK(n) 

LinkState  =  CONN 
ExpectedF  =  n 
Stop  START  timer 

CONNectedl  "n"  is  the 
frame  seq.  #  other 
end  will  start  using. 

AMDISC 
[DISC] 

FR  1  =  START  & 
FR  1=  AMDISC 

send  AMDISC 

Tell  other  end  we're 
Disconnected 

haveDISC 
[waiting_DISC] 

(FR==  AMDISC  or 
FR==DISC)& 
buffered  =  =  0 

receivedDISC  =  true 

Finally  got  it!! 
(toDISC  may  be 
true  nowl) 
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Transition 


Enabling  Pred. 


timeouts  STARTtimer  timeout 

[waitingCONN]  &  attempts  < 
MAXattempts 


Action 

attempts  +  + 
send  START 
start  STARTtimer 


stayDISC  FR==DISCor  LinkState  =  DISC 

[waitingCONN  >    (STARTtimer  timeout  print  "Cant  CONNectl" 

DISC]  &  attempts  >  -  Send  DISC 

MAXattempts) 


Meaning 

Continue  CONN 
attempt. 


Can!  CONNect  Unkll 


DISC 
[CONN> 
waiting_DISC] 

user  transaction 
fcontrol(DISC) 

LinkState  •-  waitingDISC 
attempts  =  0 
receivedDISC  -false 
start  DISCtimer 

User  want's  DISC. 

(WDISC  may  be 
true  immediately!) 

DISCL 
[CONN> 
waiting_DISC] 

FFI==DISC 

LinkState  -  waiting  DISC 
attempts  ■  0 
receivedDISC = true 
start  DISCtimer 

Link  want's  DISC. 

(toDISC  may  be 
true  immediately!) 

timeoutD 
[waitingDISC] 

DISCtimer  timeout 
&  attempts  < 
MAXDattempts 

attempts  +  + 
send  DISC 
start  DISCtimer 

Continue  DISC 
attempt. 

stay 
[waiting  DISC> 
CONN] 

DISCtimer  timeout 
&  attempts  >  = 
MAXDattempts 

LinkState  =  CONN 
print  "Cant  DISConnectI" 
if  (buffered  ==0) 

ExpectedA  =  NextF  =  0 

send  START 

Cant  Disconnect  link! 

(Send  START  if  possibli 
to  force  other  end  to 
CONN) 

Note:  The  following  Transitions  are  tested  after  any  of  the  proceeding  Actions  and 
when  (buffered  =  =  0)  is  true  [due  to  Data  Transfer  sub  -  layer  action]. 
In  effect,  "buffered  =  =  0"  is  an  "event"  that  causes  the  Predicates  to  be  tested. 


Transition 

WDISC 
[waitingDISC] 

toDISC 
[waitingDISC  > 
DISC] 


Enabling  Pred. 
buffered  ==0& 
receivedDISC  false 

buffered  =  =0& 
receivedDISC  true 


Acton 
send  DISC 

receivedDISC  - 


waiting 


LinkState  =  DISC 

send  AMDISC 
stop  DISCtimer 
ExpectedF  =  NextF  =  0 
BpectedA  =  0 


Meaning 

Ready  to  tell  other 
end  to  DISC. 

Finally  Disconnected!! 


Figure  10.    Link  Control  Diagram  (Part  II) 
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3.9  Operation  Scenarios 

The  remainder  of  this  chapter  demonstrates  the  performance  of  the  various  sublayers  just 
described.  No  attempt  has  been  made  to  show  all  possible  sequences  within  each  sublayer. 
However,  all  non-trivial  transitions  within  each  of  the  link  Control  and  Data  Transfer 
sublayers  are  used  by  at  least  one  scenario.  The  scenarios  use  a  time  sequence  diagram  to 
show  the  transmission  and  reception  of  frames  and  their  relationship  to  the  peer  sublayer  at 
the  other  end  of  the  link. 

The  diagram  is  read  from  the  top  down.  The  left  side  of  page  represents  one  end  of  the  link, 
the  right  represents  the  other.  Across  the  page,  the  first  column  represents  the  state  of  the 
Data  Transfer  or  Link  Control  variables  of  interest  in  that  scenario.  Next  is  a  field 
describing  the  frame  being  sent  or  received.  The  center  (usually  white)  column  represents 
the  physical  link,  with  comments  occasionally  indicating  something  other  than  normal 
transmission.  The  remaining  two  columns  represent  the  frame  being  sent  or  received  and  the 
state  variables  of  interest,  respectively,  for  the  other  end  of  the  link.  Events  occurring  at  the 
same  time  or  in  random  order  arc  represented  by  having  them  appear  on  the  same  line  of  the 
diagram. 

A  shorthand  method  of  describing  each  frame  is  used.  The  frame  type  is  identified  by  its 
acronym  (see  "Frame  types  and  layout"  above),  followed  by  the  sequence  number  and 
acknowledgement  number,  where  applicable.  Since  the  sequence  number  applies  only  to 
INFO  frames,  any  number  following  other  frame  types  is  the  acknowledgement  number. 

A  "+"  before  the  frame  type  indicates  reception  of  that  frame,  a  "-"  indicates  the  frame  is 
being  transmitted.    The  value  (before  reception  or  transmission)  of  the  Data  Transfer 
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variables  [ExpectedF,  ExpectedA  and  NextF]  are  represented  in  some  instances  as  "[x.y.z]" 
on  the  appropriate  side  of  the  page,  with  "-"  indicating  a  "don't  care"  value  of  the  associated 
variable.  The  center  of  the  page  represents  the  physical  link,  normally  blank.  An  X 
indicates  the  associated  frame  was  damaged  in  transit  while  an  L  indicates  the  frame  was 
lost 

Another  shorthand  notation  indicates  that  the  user's  message  was  removed  from  the 
"unacknowledged  frame"  buffer.  This  is  represented  as  "-msgN,"  typically  next  to  the 
reception  of  an  ACK,  where  N  represents  the  frame  sequence  number.  The  notation 
"— hostN"  will  be  used  to  indicate  that  a  received  frame  with  sequence  number  N  has  been 
passed  up  to  the  Network  routing  process  (in  order  and  without  duplication). 
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Lighttraffic  -  single  INFO,  ACK,  then  single  INFO,  return  INFO  with  piggyback  ACK,  ACK 

Bracketed  Variables  are  (ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)] .  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Acton"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


Node  A 

EF.EANF      Frames  or  <  Event  > 


Physical 

Link 


| Initial  State} 


NodeB 

-*     Frames  or  <  Event >      EF.EANF 


[0,0,0] 

[0,0,1]  -INFO0.7 

+  INFO0.7 
{B  receives  Frame  in  sequence.sends  to  Network  Layer  ('Tiosf')} 


[0,0,0] 
[1,0,0] -hostO 


<  ACKtimeout  > 
-ACK.0 


[0,1,1] -msgO     +ACK.0 


{Link  quiet,  time  passes...} 


[0,1,2] 


-INF01.7 


+  INF01.7  [2,0,0] -hostl 

{Reverse  traffic  ACKs  the  INF01 ,7  Frame} 

-INFO0.1  [2,0,1] 

[1,2,2]-msg1       +INFO0.1 
-hostO 


<  ACKtimeout  > 
-ACK.0 


+  ACK.0 


[2,0,1]  -msgO 


{Link  quiet,  time  passes...} 


Figure  11.    Normal  Data  Transfer  -  Light  Traffic 
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Maximum  1  -way  traffic    -   7  INFOs,  then  window  full,  ACK,  more  INFOs 

Bracketed  Variables  are  [ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 

Node  A  Physical  Node  B 

Link 
EF.EANF      Frames  or  <  Event > ►     Frames  or  <  Event >      EF.EANF 

[0,0,0]  (Initial  State}  [0,0,0] 

[0,0,1]  -INFO0.7 

+  INFO0.7  [1,0,0] -hostO 

{B  receives  Frame  in  sequence.sends  to  Network  Layer  ('host")} 

[0,0,2]  -INF01.7 

[0,0,3]  -  INF02.7 

[0,0,4]  -INF03.7  (A  sends  a  burst  of  INFOs} 

[0,0,5]  -INF04.7 

[0,0,6]  -INF05.7 

[0,0,7]  -  INF06.7  (Window  full,  wait  for  incoming  Frames  from  B} 

+  INF01,7  [2,0,0] -hostl 

+  INF02.7  [3,0,0]  -host2 

+  INF03.7  [4,0,0] -host3 

+  INF04.7  [5,0,0]  -host4 

+  INF05.7  [6,0,0] -host5 

+  INF06.7  [7,0,0]  -host6 

{A's  window  is  still  full...} 

<  ACKtimeout  > 

-ACK.6       (ExpectedF-1) 

[0,7,7]  +ACK.6 

-  msgO,  -  msgl ...,  -  msg6       (Remove  messages  from  window} 

(If  there  are  Frames  in  the  Request  Queue,  up  to  7  more  of  them 
will  be  sent  by  ACK  HANDLER  Action} 


Figure  12.     Normal  Data  Transfer  -  Max.  one -way  Traffic 


-45  - 

Maximum  2  -  way  traffic   -   INFOs  in  each  direction  ACKing  prior  INFOs 

Bracketed  Variables  are  (ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processedfl.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


N« 

EF.EANF     Fra 

Dde  A                              Physical 
Unk 

NodeB 

■     Frames  or  <  Event  > 

EF.EANF 

10,0,0] 
[0,0,1] 

{Initial  State} 
-INFO0.7 

-INFO0.7 

[0,0,0] 
[0,0,11 

[1,0,1]  -hostO 

+  INFO0.7 

{Neither  INFO  has  yet  been 

+  INFO0.7 
ACKed} 

[1,0,1] -hostO 

[1,0,2] 
[1,0,3] 

-  INF01 ,0   {Each  sends  piggyback 

-  INFO2.0      ACKs  for  INFO0} 

-INFO1.0 
-INFO2.0 

[1,0,2] 
[1,0,3] 

[2,1,3]  -hostl 
[3,1,3]  -host2 

+  INFO1.0 
+  INFO2.0 

+  INFO1.0 
+  INFO2.0 

[2,1,3] -hostl 
[3,1,3] -host2 

{Now  Frames  1  and  2  are  unacknowledged} 
{Further  traffic  or  ACKtimeouts  will  acknowledge  them} 


Figure  13.    Normal  Data  Transfer  -  Max.  two -way  Traffic 
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Light  traffic  -  single  INFO,  lost,  Frame  timeout 


Bracketed  Variables  are  [ExpectedF(EF),  Expected A(E A),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


EF.EANF 

[0,0,0] 
[0,0,1] 

Node  A 

Frames  or  <  Event  > 
-  INFO0.7 

Physical 
Unk 

NodeB 

Frames  or  <  Event  > 

EF.EANF 
[0,0,0] 

{Initial  State} 
Lost  Frame 

<  Frame  timeout  > 

-  INFO0.7 

+  INFO0.7 


[1,0,0] -hostO 


<  ACKtimeout  > 
-ACK.0 


[0,1,1] -msgO     +ACK.0        {Finally  got  acknowledgement} 


Figure  14.     Data  Transfer  Failure  -  lost  INFO/ACK 
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Frame  timeout  occurs  before  ACK  gets  back  to  Frame's  sender 


Bracketed  Variables  are  [ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


Node  A 

EF.EA.NF      Frames  or  <  Event  > 

P,0,0] 
[0,0,1] 


-INFO0.7 


Physical 

Link 


{Initial  State} 


NodeB 

Frames  or  <  Event  >      EF.EA.NF 
P,0,0] 


+  INFO0.7 


[1,0,0] -hostO 


<  ACKtimeout  > 
<  Frame  timeout >  -ACK  0 

-INFO0.7 
{Frame  timeout  interval  is  so  short  that  the  ACK  from  B  hasn't  come  back  yet...} 

[0,1,1] -msgO    +ACK.0  {ACK  finally  arrives} 

{So  does  the  re -transmitted  INFO}        -INFO0.7   {Out -of -sequence!!} 

-  NACK.0  {DoNack  now  false} 
+  NACK.O       {NACK  does  NOT  cause  retransmission} 


Figure  15.     Data  Transfer  Failure  -  Short  Timeout 
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Heavy  1  -way  traffic  with  1  lost  INFO 


Bracketed  Variables  are  [ExpectedF(EF),  Expected A(E A),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.) 


EF.EANF 

P.0,0] 
[0,0,1] 
[0,0,2] 
[0,0,3] 
[0,0,4] 
[0,0,5] 

Node  A 

Frames  or  <  Event  > 

-  INFO0.7 
-INF01.7 

-  INF02.7 

-  INF03.7 

-  INF04.7 

Physical 
Unk 

NodeB 

Frames  or  <  Event  > 

+  INF00.7 

+  INF01.7 
+  INF02.7 

EF.EANF 
[0,0,0] 

[1,0,0] -hostO 

[2,0,0]  -hostt 
[3,0,0] -host2 

{Initial  State} 
Lost  INF03I 

[0,3,5] -msgO  +NACK.2 
-msgl  -INF03.7 
-msg2      -INF04.7 


+  INF04.7  {Out-of-Sequencel!) 

-NACK.2  {DoNack  now  false) 

(NACK  piggyback  ACK  allows  INFOO/1/2  to  be  removed  from) 
{window,  and  causes  INF03  and  up  to  be  re  -transmitted.) 

-INF03.7  [4,0,0] -host3 

-INF04.7  [5,0,0] -host4 


<  ACKtimeout  > 
-ACK.4 


[0,5,5] -msg3 
-msg4 


^CK,4 


(Finally,  all  INFOs  Acknowledged} 


{Link  quiet  once  again) 


Figure  16.    Data  Transfer  Failure  -  lost  INFO  in  Heavy  Traffic 
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Heavy  Traffic,  several  lost  INFOs 


Bracketed  Variables  are  [ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


Node  A 

EF.EANF      Frames  or  <  Even 

Physical 
Unk 

NodeB 

w         Cramae  rtr   ^  PwAnt  >*         PP  PA  KIP 

i>        * 

*       rrames  or  <:  event  >       cr»EM.r»r 

[0,0,0] 

{Initial  State} 

[0,0,0] 

[0,0,1] 
[0,0,2] 
[0,0,3] 

-INFO0.7 
-INF01.7 
-INF02.7 

+  INFO0.7                    [1,0,0] -hostO 

[0,0,4] 
[0,0,5] 
[0,0,6] 

-INF03.7 

-  INF04.7 

-  INF05.7 

Lost  INF03I 
Lost  INF04I 

+  INF01.7                    [2,0,0] -hostl 
+  INF02.7                    [3,0,0] -host2 

+  INF05.7  {Out-of-Sequencell} 

-NACK.2  {DoNack  now  false} 

[0,3,6]  -msgO 
-msgl 
-msg2 

+  NACK.2 
-INF03.7 
-INF04.7 
-  INFOS.7 

{NACK  piggyback  ACK  allows  INFO0/1/2  to  be  removed  from} 
{window,  and  causes  INF03  and  up  to  be  re  -transmitted.} 

Lost  INFQ4I 

[0,4,6]  -msg3  +NACK.3 
-INF04.7 
-INF05.7 


HNF03.7  [4,0,0]  -host3 

{INFO  in  sequence,  so  DoNack  is  true.} 
+  INFOS, 7  {Out-of-Sequencell} 
-NACK.3  {DoNack  now  false} 


+  INF04.7 
+  INF05.7 


[5,0,0] -host4 
[6,0,0] -hosts 


<  ACKtimeout  > 
-ACK.5 


[0,6,6] -msg4 
-msg5 


+  ACK.5 


{Finally,  all  INFOs  ACKnowledged) 


{Link  quiet  once  again} 


Figure  17.     Data  Transfer  Failure  -  Many  lost  INFOs 
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Light  1  -way  traffic  -  single  INFO,  lost  ACK and  NACK 

Bracketed  Variables  are  [ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.} 


EF.EA.NF 

Node  A 

Frames  or  <  Event  > 

Physical 
Unk 

NodeB 

Frames  or  <  Event  >      EF.EA.NF 

10,0,0] 
[0,0,1] 

-INFO0.7 

{Initial  State} 

[0,0,0] 
+  INFO0.7                   [1,0,0] -hostO 

Lost  ACK 

<  AC Ktimeout  > 
-ACK.0 

<  Frame  timeout  > 

-INFO0.7 

+  INFO0.7  {Out-of-Sequencell} 

<  Frame  timeout  > 

Lost  NACK 

-NACK.0  {DoNack  now  false} 

-  INFO0.7 


<  Frame  timeout  > 


+  INFO0.7  {Still  bad  seq.  number.} 
{DoNack  false,  donl  send  NACK} 


-INFO0.7 

+  INFO0.7  {Still  bad  seq.  number.} 
{DoNack  false,  don't  send  NACK} 
{Protocol  is  "stalled"  due  to  loss  of  a  NACK  after  ACK/piggyback  ACK} 
{INFO  has  actually  arrived,  and  a  new  INFO  from  either  direction  will} 
{"unstall"  the  protocol,  so  the  only  real  problem  here  is  that  the  Link  is} 
{incurring  a  lot  of  wasted  re  -  transmission.  A  HEARtbeat  from  B  to  A} 
{eventually  fixes  things,  but  actually  almost  any  kind  of  Frame  would  do.} 


<  HE  ARtimeout  > 
-HEAR.0 


[0,1,1] -msgO     +HEAR.0 


{Link  quiet  once  again} 


Figure  18.     Data  Transfer  Failure  -  Stalled  without  Traffic 
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Normal  CONNect  request  while  in  DISC  state 


Variables  are  [LinkState(LS),ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
(Comments  are  shown  this  way.}.   'VvDISC"  means  "waitingDISC;  ditto  for  "wCONN". 


Node  A 

LS.EF.EA.NF    Frames  or  <  Event  > 
[DISC,0,u,0] 


Physical 

Link 


(Initial  State} 


NodeB 


■+      Frames  or  <  Event  > 


LS.EF.EA.NF 
[DISC,0,0,0] 


[w_CONN,0,0,0]  <fcontrol(CONN)> 
-START 


[CONN,0,U,0]    +  STACK.0 


(The  Link  is  now  '\jp"ll} 


+ START 
-STACK.O 


[CONN,0,0,0] 


Figure  19.    Normal  Link  Control  -  Connect 
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Normal  Disconnect  request  while  In  CONN  state 

Variables  are  [LinkState(LS),ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processedfl.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.}.   "w_DISC"  means  "warSng_DISC;  ditto  for  "wCONN". 

Node  A  Physical  Node  B 

Link 
LS.EF.EANF    Frames  or  <Ewnt> ►      Frames  or  <  Event  >      LS.EF.EA.NF 

[CONN,3,5,5]  {Initial  State}  [CONN,5,3,3] 

{"receivedDISC"  is  false  until  'buffered"  is  0} 
{Assume  'buffered"  is  0,  all  Frames  have  been  ACKnowledged} 

[w_DISC,3,5,5]  <fcontrol(DISC)> 

-DISC.2 
(receivedDISC  = waiting} 

+  DISC.2  [w_DISC,S,3,3] 

{receivedDISC  =true} 
-AMDISC  [DISC,0,0,0] 

[DISC.0,0,01         +  AMDISC 

{The  Link  is  now  "down"ll} 


Figure  20.    Normal  Link  Control  -  Disconnect 
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Normal  Disconnect  request  while  In  CONN  state  -  unacknowledged  Frames 

Variables  are  [LinkState(LS),ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.}.   "wDISC"  means  "waitingDISC;  ditto  for  "wCONN". 

Node  A  Physical  Node  B 

Link 
LS.EF.EA.NF    Frames  or  <  Event >     « ►     Frames  or  <  Event >      LS.EF.EA.NF 

[CONN,3,4,5]  {Initial  State}  [CONN,5,2,3] 

{Node  A  has  INF04  unACKnowledged  and  Node  B  has  INF02  unACKnowledged} 

<fcontrol(DISC)> 

{"receivedDISC"  is  false  until  'buffered"  is  0} 

"Mien  'buffered"  is  0,  all  Frames  have  been  ACKnowledged} 

<ACKtimeout> 

-ACK.4 

[CONN,3,5,5]    +ACK.4  {Node  A,  buffered  ==  0  now} 

[W_DISC,3,5,5]  -DISC.2 
{receivedDISC  =waiting} 

+  DISC.2  [w_DISC,5,3,3] 

{receivedDISC  =true} 

{The  DISC  acted  as  piggyback  ACK  for  Node  B} 

-AMDISC  [DISC,0,0,0] 

[DISC,0,0,0]         +AMDISC 

{The  Link  is  now  "down"!!} 


Figure  21 .    Normal  Link  Control  -  Disconnect  with  Traffic 
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Incoming  CONN  while  in  "CONN"  slate  -  Could  be  "crashed"  node  coming  up 

Variables  are  [LinkState(LS),ExpectedF(EF),  Expected A(E A),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processedO.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
(Comments  are  shown  this  way.}.   "wDISC"  means  "waiting  DISC;  ditto  for  "w  CONN". 

Node  A  Physical  Node  B 

Link 
LS.EF.EA.NF    Frames  or  <  Event > ►     Frames  or  <  Event  >      LS.EF.EA.NF 

[CONN.4,6,7]  {Initial  State}  [DISC,0,u,0] 

{Node  B  just  coming  up  after  "crash",  attempts  CONN} 
<fcontrol(CONN)> 
-  START  [w_CONN,0,0,0] 

[CONN,0,6,7]  +  START  {INF06  has  not  been  acknowledged} 
-STACK.6 
-INF06.7 

+  STACK.6  [CONN,6,0,0] 

+  INF06.7  [CONN,7,0,0] 

<  ACKtimeout  > 
-ACK.6 

[CONN,0,7,7]    +ACK.6 
-msgO 

{INFO  Frame  6  survived  the  crash  of  Node  B} 


Figure  22.     Link  Control  Failure  -  Stray  Connect 
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CONNect  request  with  lost  START 

Variables  are  [LJnkState(LS),ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e.,  "Acton"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.).   "w_DISC"  means  "waitingDISC;  ditto  for  "wCONN". 

Node  A  Physical  Node  B 

Unk 
LS.EF.EA.NF    Frames  or  <  Event >     •« ►     Frames  or  <  Event  >      LS.EF.EA.NF 

[DISC,0,0,0]  {Initial  State}  [DISC,0,0,0] 

[w  CONN,0,0,0]  <fcontrol(CONN)> 
-START 

Lost  Start 

<STARTtimeout> 

-  START  {attempts  still  <  MAXattempts,  so  send  another  START} 


+  START  [CONN,U,0,0] 

-STACK.0 

[CONN,0,0,0]    +  STACK," 

{The  Link  is  now  "up"ll} 


Figure  23.     Link  Control  Failure  -  Lost  START 
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CONNect  from  both  ends  while  in  DISC  state 

Variables  are  [LinkState(LS),ExpectedF(EF),  ExpectedA(EA),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processedfi.e.,  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.}.   "wDISC"  means  "waitngDISC;  ditto  for  "wCONN". 

Node  A  Physical  Node  B 

Link 

LS.EF.EA.NF    Frames  or  <  EYent >     « ►     Frames  or  <  Event >      LS.EF.EA.NF 

[DISC, 0,0,01  {Initial  State}  [DISC,0,0,0j 

<fcontrol(CONN)>  <fcontrol(CONN)> 

[w_CONN,0,rj,0]    -START  -START  [w_CONN,0,0,0] 

{"Frames  pass  in  the  night"} 


[CONN.0,0,0]         +  START  +  S"n  [CONN.0,0,0] 

-STACK,"  -STACK.0 

+  STACK.O     {STACK  ignored  in  CONN}  +  STACK," 


{Note  that  loss  of  either  START  will  cause  STARTtimeout  and  force  another  START} 
{When  the  START  is  finally  received,  a  STACK  is  always  returned,  allowing  the  node} 
{to  move  from  'Vi  CONN"  to  "CONN"  state.} 


Figure  24.     Link  Control  Failure  -  Double  Connect 
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Disconnect  from  both  ends  while  in  CONN  state 

Variables  are  [LinkState(LS),ExpectedF(EF),  Expected A(E A),  and  NextF(NF)].  They  are  only 
shown  when  a  change  in  value  occurs  and  reflect  the  values  after  the  Frame  or  <  event  > 
is  processed(i.e„  "Action"  portion  of  applicable  transition  diagram(s)  has/have  finished.). 
<  Events  other  than  Frame  transmission/reception  are  shown  like  this.  >  and 
{Comments  are  shown  this  way.}.   "wDISC"  means  "waitingDISC;  ditto  for  "wCONN". 

Node  A  Physical  Node  B 

Link 

LS.EF.EA.NF    Frames  or  <  Event >     ■• ►     Frames  or  <  Event >     LS.EF.EA.NF 

[CONN,2,4,4]  {Initial  State}  [CONN,4,2,2| 

(No  unACKnowledged  Frames} 
<fcontrol(DISC)>  <fcontrol(DISC)> 

lw_DISC,2,4,4]      -DISC.1  -DISC.3  [w_DISC,4,2,2] 

{"Frames  pass  in  the  night'} 


[DISC.0,0,0]  +DISC.3  +DISC'1  [DISC.0,0,0] 

-AMDISC  "AMDISC 

+  AMDISC      {AMDISC  ignored  in  DISC}  +  AMDISC 


{Note  that  loss  of  either  DISC  will  cause  DISCtimeout  and  force  another  DISC} 
{When  the  DISC  is  finally  received,  an  AMDISC  is  always  returned,  allowing  the  node} 
{to  move  from  'VvDISC'to  "DISC"  state.} 


Figure  25.     Link  Control  Failure  -  Double  Disconnect 
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4.  IMPLEMENTATION 

Implementation  of  the  protocol  from  the  previous  chapter  is  in  the  Concurrent  C  [Geh84] 
language  running  on  a  VAX  11/780  under  the  4.2  Berkeley  Software  Distribution  version  of 
UNIX™.  The  choice  of  the  implementation  language  was  made  with  the  knowledge  that 
Concurrent  C  was  not  (yet)  well-known  and  that  transportation  of  the  protocol  to  other 
systems  would  not  be  trivial.  However,  Concurrent  C  does  provide  an  easily  understood 
method  of  process  interaction.  Many  of  the  transitions  appearing  in  the  modified  state 
transition  diagrams  can  be  mapped  into  Concurrent  C  in  an  obvious  manner.  Thus  the  leap 
from  diagram  to  code  is  not  so  difficult,  and  there  is  less  chance  of  incorrectly  translating  a 
protocol  description  into  code. 

4.1   Concurrent  C  Facilities 

A  short  summary  of  the  facilities  provided  in  Concurrent  C  will  aid  in  understanding  the 
implementation  (and  the  comments  in  this  chapter).  Concurrent  C  allows  processes  to 
interact  through  a  concept  called  the  extended  rendezvous;  two  processes  request  the 
rendezvous,  synchronize  and  exchange  information  and  then  continue  their  concurrent 
operation.  The  two  processes  are  not  equals  during  a  rendezvous.  One  process  requests  the 
rendezvous  while  the  other  accepts  the  request;  the  request  and  accept  can  be  executed 
asynchronously  and  each  will  wait  on  the  other.  However,  the  accepting  process  is  allowed 
to  accept  requests  from  multiple  processes  and  may  even  have  multiple  types  of  accepts  all 
open  at  the  same  time.   The  requesting  process  is  allowed  only  one  pending  request  to  one 

UNIX  k  a  trademark  of  AT&T  Bd!  Uboretonei. 
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process  at  any  one  time.  It  is  possible  to  revoke  the  request,  but  typically  the  requester  is 
blocked  until  the  request  is  accepted13. 

In  addition  to  the  Concurrent  C  language,  a  facility  called  the  Concurrent  C  Window 
Manager  [Smi84]  is  provided.  On  UNIX,  the  Window  Manager  allows  controlled 
interaction  with  various  processes  within  a  Concurrent  C  program  from  a  single  display 
terminal.  Input  can  be  directed  to  individual  processes,  even  though  several  may  be 
requesting  input  simultaneously.  Output  is  directed  to  virtual  windows,  and  the  Window 
Manager  controls  which  virtual  windows  appear  on  the  terminal  at  any  given  time. 

42  Implementation  Structure 

The  approach  of  mapping  each  protocol  sub-layer  into  Concurrent  C  processes  was  not  used 
in  this  implementation.  Such  a  mapping  would  require  the  use  of  monitors  or  buffer 
processes  between  many  of  the  protocol  processes  to  prevent  blockage.  Efficiency  would 
suffer  from  the  operation  of  several  small  protocols  on  each  frame.  Therefore,  the  sublayers 
were  combined  back  into  the  two  levels  that  Comer  used,  a  Frame  level  and  a  Data  Link 
level.  The  processes  bear  the  same  names  as  Comer's  Link  layer  processes,  but  communicate 
via  Concurrent  C  transactions  rather  than  global  data  structures,  semaphores  and  interprocess 


The  processes  also  perform  somewhat  different  tasks  at  the  Frame  level  than  the 
corresponding  processes  in  Comer's  implementation.  Rather  than  using  separate  input  and 
output  processes  cooperating  to  implement  the  Frame  level  protocol  (as  in  Comer),  the 


15.  There  may  be  an  analogy  in  male/female  protocols  (social  etiquette  in  accepting  invitations),  but  I  will  leave  that  investigation  to 
others.   {See  [Pos55]  or  for  a  more  formal  treatment,  [McC77].) 
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Frame  level  protocol  is  placed  entirely  within  one  process,  /output.  Anfinput  process  is  still 
used,  but  only  to  retrieve  incoming  frames  from  the  Data  Link  layer,  notify  /output  and  send 
acknowledged  frames  up  to  the  Network  layer.  The  result  of  this  shuffling  is  called  the 
Implementation  Model.  A  diagram  of  the  processes  and  protocol  placement  follows. 
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Other  "Link's 

fvdmsg, 
forwardmsg 


Leuels 


Network 


Frame  protocol 


Link  Output  protoco 


combined  Link  Control  and  Data  Transfer  protoco] 
Framing  and  Transparency  (output)  protocol 


Link  Input  protocol 


combined  Framing  and  Transparency  (input) 
and  Error  Detection  protocol. 
Labeled  arcs  are  Concurrent  C  transactions,  the  accepting  process 
is  at  the  arrowhead  end  of  the  arc. 

Figure  26.    Implementation  Model 
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4.3  Implementation  Model 

The  Implementation  Model  (just  "Model"  from  now  on)  provides  a  fixed  set  of  services 
between  a  limited  number  of  processes  and  assumes  that  the  protocol  will  fit  into  the 
indicated  places  without  resorting  to  the  use  of  global  variables  or  communication  paths 
other  than  those  shown.  Thus,  while  the  Model  can  certainly  support  the  extended  protocol 
described  in  the  previous  chapter,  it  can  also  support  alternative  protocols.  Appendix  1 
shows  the  pseudo-code  for  the  Concurrent  C  processes  implementing  the  Model.  Where 
[ ...  protocol  ]  is  shown,  the  appropriate  portion  of  the  protocol  is  executed. 

In  general,  the  Model  operates  by  accepting  packets  from  user  processes  and  the  froute 
process,  and  delivers  them  to  the  dlcoin  process  for  transmission.  The  flnput  process  waits  on 
dlciin  to  read  a  packet  (or  indicate  reception  of  a  damaged  packet),  then  passes  the  frame  to 
/output  for  analysis.  The  status  returned  by  /output  determines  whether  the  frame  is  passed 
up  to  the  froute  process.  The  heart  of  the  retransmission  and  sequencing  of  frames  is 
controlled  by  /output.  The  service  process  is  a  concession  to  efficiency.  It  provides  a  frame 
management  service  that  allows  frame  addresses  to  be  passed  between  the  processes  at  the 
Frame  and  Data  Link  levels,  instead  of  copying  the  data. 

4.4  Implementation 

The  protocols  from  the  previous  chapter  are  implemented  within  the  Model  using,  where 
appropriate,  code  that  reflects  the  state  transition  diagrams.  It  is  thus  not  difficult  to 
determine  that  the  protocol  code  matches  the  diagrams  closely.  Many  of  the  predicates 
placed  on  transitions  in  the  diagrams  are  handled  by  guards  and  other  facilities  provided  in 
Concurrent  C. 
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Appendix  2  contains  the  code  for  the  implementation,  as  well  as  supporting  files. 

4  J  Test  Facilities 

To  allow  control  and  monitoring  of  various  processes  in  the  Model,  a  process  called  Monitor 
was  implemented.  This  process  reads  test  control  input  from  a  Virtual  Window  and  acts 
upon  that  input.  Associated  with  each  link's  processes  and  with  the  local  network  layer's 
processes  is  a  block  of  Monitor  variables  accessible  only  by  those  processes  and  by  the 
Monitor  process.   The  input  to  Monitor  is  one  of  the  following  (where  var  is  the  name  of  a 

Monitor  variable): 

~Mx  -  enter  Monitor  variable  access  mode  for  the  nodelD  or  linkID 

specified  by  V  (required  before  the  following  inputs  apply), 

d  var  -  display  the  value  of  the  Monitor  variable  var, 

d  -  display  the  value  of  all  Monitor  variables, 

svar  -set  var  to  1, 

r  var  -  reset  var  to  0  and 

Q  -  exit  Monitor  access  mode. 

Dump,  set  and  reset  are  rather  primitive,  but  provide  the  means  to  control  and  monitor  the 
other  processes.  This  is  accomplished  by  placing  some  "instrumentation''  code  within  each  of 
the  processes.  The  instrumentation  code  allows  limited  access  to  the  Monitor  variables16. 
Each  variable  is  used  in  one  of  three  ways;  as  a  counter,  picture  or  flag. 

A  counter  variable  is  incremented  each  time  the 
COUNT (var) j 


16.  Concurrent  C  does  not  allow  access  directly  to  global  variables  from  a  process,  nor  U  a  process  such  as  Monitor  allowed  access  to 
the  local  variables  of  other  processes.  The  only  mechanism  (besides  transactions)  for  communicating  between  processes  is  global 
variables,  but  they  must  be  accessed  by  functions  defined  outside  the  processes. 
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statement  appears  in  the  Concurrent  C  code.  The  counter  variables  (and  the  others)  are 
initially  0. 

A  picture  variable  provides  a  means  to  tell  Monitor  an  (integer)  value  last  computed  at  some 
point  within  a  process.  For  example, 

PICTURE [var, value) ; 
takes  a  snapshot  by  placing  "value"  into  the  Monitor  variable  "var." 

A  flag  variable  controls  the  execution  of  alternative  code,  based  on  the  variable  being  "set" 

or  "reset."  For  example,  to  simulate  the  effect  of  a  lost  ACK  when  "var"  is  "set," 

if    (    !    PLAG(var)    )    { 
send  ACK; 
} 

or  to  block  a  process  from  further  execution, 

vh±le(    PLAG(var)    )   delay  1; 

The  Monitor  variables  are  defined  at  the  beginning  of  each  compiled  unit  in  a  complex 
structure  and  must  be  initialized  there.  This  requirement  is  most  conveniently  met  through 
the  use  of  macros  defined  in  the  C  header  file  "monvars.h". 

Snce  Monitor  can  dump  and  change  variables  as  the  processes  execute,  it  can,  with 
intelligent  placement  of  "instrumentation,"  be  used  to  trace  a  process's  execution  and  to 
control  dynamically  the  failure  testing  of  a  protocol. 

4.6  Protocol  Testing 

The  protocol's  processes  (collectively  called  Proto)  can  be  tested  by  executing  Prow  twice 
(from  two  separate  display  terminals).  In  this  instance,  two  arguments  must  be  provided  to 
Proto,  one  is  the  nodelD  of  this  instance  of  Proto  and  the  other  combines  the  linkID  used  by 
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Proto  to  identify  the  (single)  link  and  the  name  of  the  I/O  port  acting  as  this  end  of  the 
physical  link.  The  ports  must  be  physically  connected  together,  of  course.  An  example  of 
input  to  begin  a  typical  test  session  is: 

Proto  A  2,/dev/tty3         [Node  A  reaches  Node  2  using  device  tty3] 

Proto  2  A,/dev/ttyi4        [Node  2  reaches  Node  A  using  device  ttyi4] 

implying  that  the  tty3  and  ttyi4  ports  are  physically  connected  together.  Many  other  test 
configurations  are  possible;  refer  to  the  manual  pages  for  "Proto." 

After  initialization,  the  Window  Manager  will  display  the  execution  status  of  some  of  the 
processes  on  the  terminal  screen.  The  contents  of  the  first  four  virtual  windows  will  also  be 
displayed.  Packet  transmission  is  initiated  through  input  to  the  virtual  window  associated 
with  a  user  process  (or  the  Monitor  window).  Access  to  Monitor  variables  is  through  input  to 
its  virtual  window  as  previously  described. 

4.7  Implementation  Limitations 

The  implementation  "works  around"  several  deficiencies  in  the  parts  from  which  it  is 
constructed.  UNIX,  in  general,  does  not  allow  controlled  inter-process  communication 
between  arbitrary  user  processes.  This  was  one  of  the  reasons  for  choosing  Concurrent  C  as 
an  implementation  language.  On  the  other  hand,  Concurrent  C  cannot  currently  maintain 
the  effect  of  concurrent  processing  when  requests  to  the  operating  system  block  execution  of 
the  underlying  UNIX  user  process.  This  limitation  (concurrency  during  operating  system 
requests)  requires,  for  example,  the  use  of  non-blocking  read  requests  from  the  input  device. 
(This  forces  a  "polling"  approach  to  read  requests,  something  that  non-concurrent  languages 


■66- 


must  typically  do.)  Protocols  that  require  a  multiplicity  of  readers  or  other  blocking  requests 
to  UNDC  will  have  difficulty  fitting  into  the  Model  and  achieving  concurrent  operation.  One 
can  hope  that  improvements  in  the  implementation  of  Concurrent  C  would  allow  "true" 
concurrency  at  the  UNDC  process  level,  perhaps  even  maintaining  the  flexibility  that  the 
Window  Manager  provides. 

Also,  the  extended  rendezvous  process  interface  of  Concurrent  C  (and  ADA)  has  difficulty 
handling  the  asynchronous  event  and  message  passing  that  is  available  in  a  "process  control" 
or  message-based  environment.  By  suitable  use  of  several  "server"  and  "buffer"  processes, 
these  difficulties  may  be  circumvented,  but  the  Implementation  Model  cannot  claim  to 
handle  such  needs. 

The  Model  itself,  given  the  above  limitations,  makes  further  assumptions  about  the  way  that 
various  processes  communicate.  For  example,  the  user-level  process  receiving  incoming 
messages  is  assumed  never  to  communicate  anything  back  down  to  the  Link  layer.  To  allow 
freceive  to  make  flow  control  requests  or  to  reject  frames  (they  have  already  been 
acknowledged)  would  require  some  major  surgery  on  the  Model. 
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5.  CONCLUSION 


This  report  has  presented  an  extended  protocol  for  the  Link  layer  of  a  computer 
communications  network.  While  based  on  an  already-published  protocol  for  ring  networks, 
the  extensions  have  removed  the  requirement  for  a  ring  architecture,  improved  error 
detection,  increased  utilization  of  the  link,  and  added  a  degree  of  control  over  the  link.  The 
result  is  a  protocol  that  provides  a  solid  base  for  further  extensions  or  for  supporting 
development  of  higher  protocol  layers. 

The  use  of  the  monitor  in  the  implementation,  together  with  the  facilities  provided  by  the 
Window  Manager,  allows  the  execution  of  the  protocol  to  be  observed  and  controlled  from  a 
single  terminal  representing  the  processes  operating  at  one  end  of  a  link.  This  provides  a 
more  satisfying  and  useful  test  facility  than  batch  test  scripts  and  reams  of  printed  output 
tracing  protocol  execution. 

As  the  applications  for  computers  increase  and  their  need  for  information  grows,  it  is  likely 
that  the  need  for  usable,  efficient  protocols  and  implementations  will  increase.  While  the 
protocol  and  implementation  described  in  this  paper  are  useful  and  reliable,  it  cannot  be 
claimed  that  the  ultimate  Link  protocol  has  been  achieved.  The  work  does,  however, 
provide  a  foundation  for  development  by  others. 

5.1  Future  Efforts 

There  are  several  areas  related  to  this  report  that  are  worthy  of  investigation.  First,  formal 
verification  of  the  protocol  would  provide  some  solid  evidence  of  the  soundness  of  the 
protocol.  Second,  Chapter  2  itemized  several  possible  extensions  that  were  not  designed  into 
the  protocol.    Some  of  these,  in  particular  the  Virtual  Circuit  capability  and  the  remote 
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control  of  nodes,  would  be  major  undertakings.  Designing  and  implementing  the  Network 
layer  routing  process  would  also  be  an  interesting  exercise. 

In  the  implementation  area,  it  would  be  informative  to  see  this  Concurrent  C  implementation 
compared  to  an  implementation  in  other  languages  supporting  concurrency.  Of  course,  an 
implementation  in  a  non-concurrent  environment  using  the  protocol  descriptions  in  Chapter  3 
would  also  be  possible.  One  interesting  non-concurrent  environment  would  be  a  micro- 
computer or  work-station,  with  all  communication  with  other  computers  using  the  protocol. 
Mapping  the  design  into  a  try  protocol  within  the  UNIX  operating  system  kernel  would 
produce  an  efficient  version  of  the  protocol.  An  alternative  would  be  placement  of  the  dlciin 
and  dlcoin  processes  into  the  kernel  (or  a  programmable  I/O  device),  with  the  Frame  level 
remaining  as  user  processes. 

It  has  been  said  that  every  communication  protocol  evolves  toward  more  complexity  until  it 
ceases  to  be  used.  As  a  project  for  those  believing  in  the  phrase  "small  is  beautiful,"  some  of 
the  extensions  could  be  removed  or  revised  and  the  resulting  protocol  compared  to  the 
original. 
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APPENDIX  1 


Original  Pseudo-code  for  the  Concurrent  C  Implementation  Model 


App.  1  -  1 

/*  NOTE:  The  first  2  pages  appear  only  for  reference  "/ 
/*  purposes  —  they  were  copied  from  "proto.h"  */ 
/*        early  m  the  design/code  phase.  */ 

/*  Universal  Constants  */ 

#define  MAXpkt  150      f*    Max.  size  of  packet  with  header.  */ 

#define  MAXlinks  3      /*  Max.  no.  of  Links  out  of  this  node  */ 

#define  MAXseq   7      /*  Highest  sequence  no.  */ 

#define  MAXfr_l  (MAXseq+2+4)  /*  Max.  frames  per  link  */ 

#define  ESC  0251 

#define  EOB  0252 

'define  SOB  0253 

#define  RESTART  0257 

#define  ESCmask  0370 

#define  ESCblt  0200 

#define  BROAD  0       /*  Destination  Implying  Broadcast  */ 

/*  Universal  Terms  */ 
#define  PUBLIC  extern 
#def1ne  PRiyATE  static 
#def Ine  LOOP  for( ; ; )  { 
#deflne  ENDLOOP  } 
#define  FNULL  (Frametype  ")0 

/*  Minimum  frame  address  is  50  to  allow  0  to  49  as  error  codes  "/ 
#def1ne  FMIN  (Frametype  *)50 

/*    Universal  Codes  */ 
enum  Status  {  NoFrame 

); 
enum  UError  {  U  OK.  U_D1sc,  U_NoL 1 nk ,  U_BadArgs  }; 
enum  Errorcode  7  NoError, 

IGNORE,  /*  foutput  ->  flnput  ■>  Ignore  frame  */ 

ROUTEMSG        /*  foutput  ->  flnput  «>  forward  to  Router  */ 

>: 
enum  Cntlreq  {  reqDISC.  reqCONN  }; 
enum  LlnkStates  {  L_DISC,  L_C0NN,  L_wai t ingDISC ,  L_wa1 t 1 ngCONN  >; 

/*  Universal  Types  */ 

typedef  enum  Status  Statustype; 

typedef  enum  U_Error  UErrortype; 

typedef  enum  Errorcode  Errortype; 

typedef  enum  Cntlreq  Cntltype; 

typedef  struct  Frame  Frametype: 

typedef  char  PkttypeU;  /*  Just  an  array  of  char  */ 

typedef  char  BOOL; 


App.  1  -  2 

/*  Universal  Structures  */ 
struct  Frame  { 

Int   con;    /*  Control  bits  for  frame  management  -  NEVER  xmitted  */ 

char  seq;    /*  Seq .  number  for  frame  */ 

char  ack;    /*  Piggybacked  ACK  seq.  0    */ 

char  len;    /*  Does  not  count  checksum  V 

char  from;   /*  Originator  of  data  */ 

char  to;     /*  Destination  of  data  */ 

char  net  type;  /*  Network  level  use  only  */ 

char  packet [ MAXpkt ] ;  /*"  Network  data   */ 
): 

ifdeflne  FHDRslze  6 
#def1ne  MAXfrsIze  sizeof  (struct  Frame) 

#def1ne  conREL  1        /*  Release  frame  when  finished  (foutput/dlcoln)  */ 
♦define  conDONE  2       /"  dlcoln  finished  xmlttlng  frame  */ 

struct  LinkTB  { 

char  id;     /*  ID  of  node  at  end  of  this  link 

'\0'  «>  Nonexistent  V 
enum  LlnkStates  state;       /*  current  state  of  this  link  */ 
mt  rdev.wdev;       /*  file  descriptor(s)  of  open  link  */ 
char  *lname;        /*  name  of  link  device  V 
process  foutput  outproc;   /*  Process  ID  of  foutput  */ 


/*  GLOBALS  V 

char  NodelD;     /*  My  name  and  serial  number  V 
struct  LinkTB  L inktable[MAXl 1 nks ] ; 


/*  FUNCTIONS  */ 

int    restartt)    {return   G_restart;} 

restartSO)    1nt    1;    <   G_restart    »    1;    > 

*lfdef  NOWM 

/*  Tie  off  c_setname  If  Window  Manager  not  used.  */ 

c  setname(l.c)  process  anytype  1;char  *c;  {  return;  > 

#endif 


App.  1  -  3 

/*  The  dlcoin  Process  (1  per  Link)  */ 

/*  Requests  frames  via  framereq,  */ 

/*  then  writes  them  to  outdevlce.  V 

/*  Private  global  used  Dy  foutput  and  dlcoin  only  */ 

/*  foutput  and  dlcoin  must  be  compiled  together  OR  G  restart  must  be  a  PUBLIC  */ 

PRIVATE  BOOL  G_restart; 

process  spec  dlco1n(process  foutput  foutp, Int  outdevlce, process  service  Serv); 

process  body  dlcolnff outp. outdevlce, Serv) 

Frametype  *tr; 
BOOL  chars_to_Xm1 t ; 

LOOP 

fr  *  foutp.f ramereq( ) ;  /*    Request  frame  to  send*/ 
If  (restartO)  {  /*  [  Flush  output  buffers  ]  */ 
restartS(O);     /•  Reset  G_restart  */ 

while  (  chars_to_Xm1t  &&  !restart{)  )  { 

/*  [  Frame  and  Transparency  Protocol  (output)  ]  */ 

1f  (fr->con  &  conREL)   Serv . rel F (f r ) ■        /•  Release  fr  (no  retransmit)  "/ 
else  fr->con  -  fr->con  |  conDONE ; 

ENDLOQP 
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/*  The  dlciln  Process  (1  per  Link)  */ 

/*  Reads  1ndev1ce,  accepts  framercv  requests        */ 
/*  from  f input  process  */ 

process  spec  dldin(1nt  indev ice, process  service  Serv) 
{ 

trans  Frametype  *framercv(); 
>: 

process  body  dlci 1n( indevice, Serv) 
{ 

Frametype  *fp  »  Serv.getF();  /*  Get  a  frame  */ 

Frametype  *ret; 

LOOP 

/•  ret  ■   [  Frame  and  Transparency  protocol  (Input)  ]  */ 

/*  +  [  Error  Detection  protocol   using  Indevice  into  fr]  */ 
accept  framercv()  {         /*  Wait  for  f input  to  ask  for  it  */ 

treturn  (ret);       /*  "ret"  could  be  a  code  or  Frame  pointer  •/ 

if  (ret  >"  FMIN) 

fr  ■  Serv.getF();        /*  Gave  frame  away  .  get  new  one  */ 
ENDLOOP 
> 


App.  1  -  5 

/*  The  foutput  Process  (1  per  Link)  */ 

/*  Handles  Frame  protocol  via  accepts.  */ 

/"  Private  global  G_restart  used  by  foutput  and  dlcoln  only  */ 

process  spec  foutput(char  node— 1d,1nt  outdev, process  service  Serv) 

trans  Frametype  *framereq();  /*  dlcoln  */ 

trans  Statustype  fwdmsg(1nt  Priority .Pkttype  pkt.char  from, 

char  to, char  len.char  net_type);    /*f route*/ 
trans  Errortype  framein( Frametype  *fr):  /*f1nput*/ 

process  body  foutput(node  Id, outdev, Serv) 
{ 

1nt  emptybufs  ■  0,  event  1  me  *  0; 

BOOL  something  to_xm1t  «  0; 

Frametype  *fr,Toldfr  »  FNULL;        /*  Frame  last  xmitted  */ 

create  dlcoln(c_mypid( ), outdev, Serv) ; 

/*  [Initial 1ze  timers,  queues]  */ 

LOOP 
select  { 

accept  f rame1n( mf r)  { 

/*  [  Frame  protocol  or  Link  Control  protocol  ]  */ 
treturn  (ROUTEMSG);   /*  [what  to  do  with  frame]  */ 
> 
or 

(emptybufs) : 
accept  f wdmsg( Pr  i  or  1 ty , pktp , f  rom , to , 1  en , net_type ) 

suchthat  (emptybufs  >  Priority)  { 
fr  ■  Serv.getF( ) j 
/*  [  Copy  packet  to  fr,  add  from,  len,  to,  net_type  ]  */ 

/*  [  Place  fr  at  end  of  forward  queue  ]  */ 
or 

(sometnlng_to_xm1 t ) i 
accept  f ramereq( )  { 

/*  [  Find  and  prepare  next  frame  to  transmit  ]  */ 

/*  [  Set   conREL   1f  frame  must  be  timed,  else  reset  ]  */ 

treturn  fr;  /*  Start  output  */ 

/*  [  Start  timer  if  needed  ]  •/ 

/*  [  If  oldfr  Is  not  timed,  dlcoln  will  release  fr  ]  */ 
oldfr  ■  fr;  /*  Remember  frame  */ 

or 

delay  eventime;  /*  Time  'tn  next  event  */ 

/*  [  Act  on  event(s) 'that  Just  timed  out,  such  as  HEARtbeat  ]  */ 

EN0L00P 


/*  The  f input  Process  (1  per  Link)  •/ 

/"  Requests  incoming  frame  via  framercv,*/ 

/"  passes  it  (or  error  indications)  via  */ 

/*  frameln,  and  then  possibly  sends  */ 

/*  it  "up"  via  Router .forwardmsg  */ 

/*  This  defines  the  interval  between  HEARtbeat  frames  and  the  number 

of  missing  pulses  that  result  in  the  "Missing  HEARtbeat"  complaint  */ 
#define  PulseGap  20  /*  3  beats/second  */ 

#define  PulseGone  3  /*  No.  missing  pulses  before  complaint  */ 

process  spec  flnputOnt  indev. process  foutput  Outproc, 

process  froute  Router .process  service  Serv); 

process  body  fmput(  indev, Outproc, Router , Serv) 
{ 

Frametype  *fr; 

Errortype  ret; 

process  did  in  did; 

int  window; 

int  missing  ■  FHDRslze;      /*  Missing  pulse  counter  */ 

did  ■  create  did  1n(  Indev,  Serv) ; 

-fifndef  NOWM 

window  =  wopen( ) ; 
#end1f 

LOOP 

fp  »  within  PulseGap  ?  did .f ramercv( )  :  FNULL;  /*  Wait  for  a  Frame  "/ 
/*  fr  >■  FMIN  *>  frame  address 
fr  ■■  FNULL  •>  missing  pulse 
fr  <  FMIN  «>  error  code      */ 
1f  (fr  ■■  FNULL)  { 

1f  (missing  >-  PulseGone)  { 
#1fndef  NOWM 

wprintf (window, "\0O7   HEARTBEAT  f allure t ! \n" ) ; 
#else 

fpdntf  (stderr. -\007   HEARTBEAT  f  ai  lure  !  1  \n"  )  ; 
#end1f 

missing  ■  0; 
) 
else 

missing  **  1j    /*  Count  missing  heartbeats  */ 
}  else  { 

If  (fr  >■  FMIN)  < 

ret  ■  Outproc. f ramein(fr) ; 
switch  (ret)  { 

case  ROUTEMSG: 

Router. forwardmsg(0, f r->packet , f r->f rom.fr- > to, 

(char) (f r->len- FHDRslze) . f r->net_type) ; 
break; 
case  IGNORE:  break;     /*  Drop  bad  frames  */ 
default:  break;         /*  Drop  other  frames,  codes  */ 
> 

Serv. rel F(f r) ;      /*  We're  done  with  frame  */ 
} 
>  /'  end  else  V 
ENDLOOP 


App.  1-7 

/*  The  f route  Process  (1  process  -  Net  Layer)  */ 

/*  Accepts  forwardmsg  request  from  f input.   */ 

/*  or  f 

/*  routes  it  to  the  proper  link  via         */ 

/*  fwdmsg.  */ 

process  spec  froutetchar  node  1d. process  rcvuser  Rcvuser, 

struct  LlnkTB  *L1hktable) 

trans  void  f orwardmsg( mt  link.Pkttype  pkt, char  from, 

char  to, char  Ten.  char  net  type); 
trans  UErrortype  f sendmsg(Pkttype  pkt, 

char  to, char  len);  /*user*/ 

trans  UErrortype  fcontrol (Cntl type  req);     /'user*/ 

process  body  froute(node  Id, Rcvuser , Llnktable) 
{ 

tnt  1  Ink .Priori ty; 
char  from.net  type; 
LOOP 
select  { 

accept  f orwardmsg( Inl Ink, pkt . from, to, len. net_type)  { 
/*  [  Routes  and  routes  and  ...  ]  */ 
Link tablet  1  ink] . outproc. fwdmsg(Pr 1or 1ty,pkt , from. to, len,net_type) j 

or 

accept  fsendmsgtpkt , to, len)  { 

/*  [  Determine  link,  from,  net  type.  Priority  ]  */ 

L1nktable[ 1  ink] .outproc. fwdmsgTPr lor 1ty, pkt , from. to, len. net_type) ; 

or 

accept  fcontrol (req)  { 

/*  [  Link  Control  Protocol  ]  •/ 

or 

terminate; 
> 
ENDLOOP 
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/*  The  user  Process  (0  or  more  processes  -  User  Interface)  */ 

/*  Makes  requests  of  the  Frame  level  via     */ 
/*  fsendmsg  and  fcontrol .  */ 

process  spec  user(process  f route  Router); 

process  body  user(Router) 
{ 

Pkttype  pkt;  char  len.dest; 

/*  [  Observe  the  user,  busily  processing  ]  */ 

/*  ...   V 

/•  ...  V 

Router . fsendmsg (pkt , dest , Ten) j 

/•  ...   V 

/•  ...  */ 

Router .fcontrol (reqDISC) ; 
/*  ...  "/ 
> 
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/*  The  rcvuser  Process  (1  process  -  Net  Layer)  */ 

process  spec  rcvuser( ) 

{       /*  Accepts  freceivemsg  request  from  f input,      "/ 
/"  does  whatever  users  do  with  packets,         */ 

trans  void  f receivemsg(Pkttype  pkt.char  from, 

char  to, char  len,  char  net  type); 

>; 

process  body  rcvuser( ) 
{ 

LOOP 

accept  f receivemsg(pkt, from, to, 1  en, net  type)  { 
/"  [  Uses  up  packets  somehow.  ..]"*/ 

}; 

ENDLOOP 
) 
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/*  The  service  Process  (1  process  -  Global  to  Node)  */ 

/*  Manages  a  node-wide  pool  of  Frames  */ 

process  spec  serv1ce(int  numFrames) 
( 

trans  Frametype  *getF(); 

trans  void  rel F( Frametype  *fr); 
>i 

process  body  service( numFrames) 
{ 

Frametype  *fp; 

mi  avail  ■  numFrames; 

/*  Build  Frame  pool  V 

LOOP 
select  { 

(avail):         /*  If  any  avail,*/ 
accept  getF()  /*  get  a  frame  */ 

{  /*  get  frame  */  ;} 
or 

accept  relF(fr)         /*  Release  frame  "/ 
{  /*  release  frame  */  ;} 
or 

terminate; 
> 
ENDLOOP 
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/*  The  monitor  Process  (1  process  -  User  Interface)  •/ 


#1fn0ef  NOMONIT 
process  spec  monitor! I; 

process  oody  mon1tor() 
{ 

/*  [  Observe  the  processes  ]  */ 
> 
»endtf 


/   The  function  main()  (invoked  first)  */ 

maln(argc.argv) 

1nt  argc;char  **argv; 

{ 

i nt  1 Inkno, Numl inks, 1  device; 

struct  LinkTB  *p : 

process  anytype  tp; 

process  service  Serv; 

process  froute  Router; 

process  rcvuser  Rcvuser; 

char  *fopname  ■  "foutO"; 
char  Vipname  »  "f1n0"; 
char  *fupname  ■  "userO"; 

/"  [Greet  the  public  and  Initialize  PUBLICS]  */ 

G  mainpid  ■  c_mypid(); 
#1fndef  NOWM 

c  setname(c_myp1d( ) . "main" ) ;  wcreatet ) ;  G_ma1nwindow»wopen( ) j 
#endlf 

/*  [Process  Input  args,  yields  Numl inks,  NodelD]  */ 

/*  Create  node-wide  processes  */ 
Rcvuser  -  create  rcvuserO; 

Router  ■  create  f route(NodeID , Rcvuser , Linktable) ; 
Serv  ■  create  service(Numl 1nks*MAXf r_1 ) ; 

argv  +■  2;   argc  -»2;       /*  Only  look  at  "dev  1d"  pairs  */ 
/*  Open  link  devices  and  create  link  processes  */ 

fort  1 1nkno-0;  1 1nkno<MAXl Inks;   1 1nkno++  )   L1nktable[l inkno] . id  *    '\0' 
for(  1 1nkno«0;  1 1nkno<Numl inks;   1 inkno++  )  { 
p  ■  &L1nktab1e[ 1 Inkno]; 
p->1d  ■  ato1(  argv[ 1 1nkno*2+1 ]  ); 
p->state  »  L_DISC; 

/"  Idevlce  ■  I  open  link  device  argv[ 1 1nkno*2]  ]  */ 
p->ldev  ■  idevlce; 
p->lname  *  argv[ 1 inkno*2] ; 
p->outproc  •  tp  ■  create  f output(NodeID , ldevice, Serv) ; 

/*  Name  That  Process  */ 
f opname[strlen(fopname)-1 ) ]  ■  '0'  +  1 inkno; 
c_setname( tp . f opname ) ; 

/*  Create  Input  handler,  passing  foutput  1n  "tp"  */ 
tp  ■  create  f Input ( Idevlce, tp, Router , Serv) ; 
f ipname[strlen(f 1pname)-1 ) j  ■  '0'  +  1 Inkno; 
c  set name ( tp, f Ipname) ; 
) 

tp  »  create  user(Router) ; 
fupname[strlen(fupname)- 1 ) ]  ■  ' 1 '  ; 
c_setname( tp, f upname) ; 
tp  ■  create  user(Router) ; 
fupname[strlen(f upname)- 1 ) ]  ■  '2 '  ; 
c  setname( tp, f upname) ; 
#1fndef  NOMONIT 

create  mon1tor( ) ; 
#endif 
) 
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/***«*»««*****«*„*»«****■     Pro to     »**»•»***********««***********-**/ 
/*     (CURRENT  VERSION  «  A.1,  see  Version  History  below) 

Proto, 
A  Robust  OSI  Layer  2  Link  Protocol 
by  Alan  L.  Varney 
Summer  1986  &  Summer  1987 

Proto  was  designed  and  Implemented  as  part  of  the  requirements  for  a 

Master's  of  Science  degree  at 
Kansas  State  University,  Manhattan,  Kansas 

Proto  is  based  primarily  on  the  design  (but  not  the  implementation) 
of  a  character-oriented  Layer  2  Link  protocol  by  Douglas  Comer  and 
documented  in  his  book, 

"Operating  System  Design:  The  XINU  Approach," 
Prent1ce-Hal 1 .  Englewood  Cliffs,  NJ.  1985 

Comer's  design  was  modified  and  enhanced  to  support  architectures  other 
than  a  ring  network  and  a  single-frame  transmit  window.   The  details, 
as  well  as  a  review  of  Link  transmission  and  protocols,  are  in  the 

"The  Design  and  Enhancement  of 
an  Existing  Data  Link  Protocol." 
by 
Alan  L.  Varney 

Masters  Report,  Kansas  State  University,  Summer  1987 

Note  that  a  printed  listing  of  Version  A.O  forms  Appendix  II  of  the  Report. 

Proto  1s  written  In  a  language  called  Concurrent  C.   It  supports  the  basic 
concept  of  an  'extended  rendevous'  model  for  concurrent  process  interaction 
and  control.   Due  to  differences  in  operation  and  support  facilities 
available  m  various  UNIX*  implementations,   Proto   can  be  "tailored"  to 
some  degree.   The  code  follows  (mostly)  a  standard  for  portable  C  coding  used 
In  various  books  by  Plum  Hall,  Cardiff.  NO.   In  particular,  the  book 

"Reliable  Data  Structures  m  C",  Plum,  Thomas  [1985] 

specified  the  format  of  data-type  Identifiers  and  some  of  the  commenting  style 
used  within  Proto.   Like  many  standards,  the  Plum  Hall  standards  for  coding 
are  not  perfect,  but  at  least  they  are  PUBLISHED  standards.   Where  convienent 
the  data-types  are  credited  to  "Plum  Hall."  These  data-type  definitions  may  be 
changed  to  tailor  Proto  to  different  machines  and  environments. 

Version  History   

(  version  name. number,  author,  date  and  reasons  for  change  ) 

Version  A.O,  Alan  L.  Varney,  12/5/86 

The  original,  untouched  Proto... 

Version  A.1,  Alan  L.  Varney,  12/13/86 

"proto. cc"  source  split  Into  "README", 
"1  Ink layer .cc"  and  "net layer .cc" , 
also  a  makefile  Introduced. 
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*  COMPILATION  OPTIONS  for  ProtO 

As  mentioned,  the  Proto  interface  can  be  changed  to  adapt  to  various  Physical 
Layer  restrictions  by  changing  the  values  associated  with  the  "Protocol  magic 
characters"  1n  the  "proto. h"  file  and  by  adding/changing  Information  1n  the 
FT_1n1t  function  code.   (Lines  consisting  of  the  "ESC_entry"  macro  call.) 

Monitor  variables  are  provided  (in  MONITOR-contalnmg  implementations)  that 
allow  control  over  TRACE  data  collection,  and  provide  event  counts  and 
snap-shots  ("pictures")  of  various  internal  process  variables.   The  Node 
has  a  table  (named  M0N_TBL)  of  its  MONITOR  variables.   Each  Link  has  a 
table  of  MONITOR  variables  defined  by  the  Mvars  pointer  in  the  Link_table 
structure.   These  variables  can  be  examined/changed  by  MONITOR.   Three 
macros  (defined  in  monvars.h)  control  the  use  of  the  variables  by  other 
processes.   The  FLAG  macro  returns  the  value  of  a  Flag-type  MONITOR  variable. 
The  COUNT  macro  increments  a  Count-type  variable,  and  the  PICTURE  macro  sets 
the  named  variable  to  a  specified  value.   Additionally,  the  TRACE  macro 
Is  a  shorthand  way  of  testing  a  FLAG  variable  and,  if  non-zero,  printing 
some  useful  output.   TRACE  1s  a  no-op  if  'BTRACE'  1s  undefined  during 
compl 1  at  ion . 

Finally,  the  functionality  of  Proto  can  be  tailored  by  "turning  off"  2  major 
parts  of  Proto.   The  "Window  Manager"  interface  can  be  turned  off  (saving 
some  space  and  much  screen  I/O  overhead),  with  the  loss  of  many  of  the 
"status"  messages  and  process  observation  capabilities  normally  available. 

For  primitive  (but  run-time  efficient)  testing,  a  MONITOR  process  is  normally 
provided  that  allows  for  the  activation  and  monitoring  of  processes  via 
comp1led-in  run-t1me  checks.   If  desired,  the  MONITOR  interface  can  also 
be  "turned  off"  at  compile  time. 

With  both  the  "Window  Manager"  and  MONITOR  removed,  Proto  has  1  computer 
terminal  (  or  "user")  Interface.   Uses  of  this  configuration  are  as  a 
remote  process  at  the  "other  end"  of  the  Data  Link  or  on  machines  where 
the  normal  configuration  strains  the  system. 

Compiling  with  the    -DNOWM    option  leaves  out  any  code  related  to 
the  "Window  Manager",  and  alters  error  messages  normally  placed  in  one  of 
the  display  windows.   If  the   NOWM   option  is  selected,  any  "routine" 
status  output  1s  directed  to  'stderr'  (  This  should  be  re-directed 
by  the  user  to  a  'log'  file.)   The  MONITOR  is  the  source  for  any  terminal 
input  with  this  option,  and  typically  generates  the  only  terminal  output, 
other  than  that  printed  by  'rcvuser'  on  receipt  of  a  valid  Packet. 
Input  to  user  processes  is  not  possible  with  this  option;  however,  the 
MONITOR  can  perform  any  action  that  a  "user"  process  could  perform. 
Major  problems  In  other  processes  may  result  in  output  at  both  the 
'standard'  and  'stderr'  outputs . 

Compiling  with  the    -DNOMONIT   option  removes  any  messages  (and  code) 
associated  with  the  MONITOR  process.   If   -DNOWM   is  also  selected, 
there  will  be  only  1  "user"  to  interact  with  Proto  directly,  receiving 
all  terminal  I/O.   This  combined  option  would  be  useful  for  a  Proto  that 
operates  as  a  central  routing  node,  or  as  a  simple  node-to-node  message 
exchange  facility.   Combining  the  two  options  during  compilation  will 
result  1n  a  small  program,  compared  to  the  "normal"  Proto  program. 

If  the  MONITOR  1s  not  removed,  several  places  within  the  source  code  contain- 
ing the  macro  TRACE  can  be  activated  by  compiling  with  the  option  -DBTRACE. 
TRACE  1s  a  macro  that  uses  the  value  of  various  MONITOR  "trace"  Flag 
variables  to  control  the  output  of  debugging  Information.   For  example, 
1f   -DEBUG   was  used  during  compilation,  setting  the  MONITOR  Flag  variable 
"rtrace"  will  result  in  debug  output  from  the  "frouteO"  net-layer  process. 
By  default,  all  trace  output  1s  disabled,  so  you  must  "Set"  the  Flags  that 
are  associated  with  the  output  you  desire. 

Several  areas  of  the  code  use  a  modified  version  of  the  ASSERT  macro  to 
explicitly  test  for  the  truth  of  conditions.   An  ASSERT  failure  results 
in  the  Proto  program  aborting,  along  with  an  error  message  pointing  to  the 
failing  assertion.   Compiling  with   -DNDEBUG   will  remove  the  assertion 
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tests,  but  this  should  be  done  only  after  thorough  debugging  of  code  changes. 

Many  of  the  alternative  compiled  versions  of  Proto  can  be  generated  using 
the  "make"  command  and  the  supplied  "makefile"  file.   See  the  front  of 
"makefile"  for  all  the  possibilities.   Enjoyl 
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#  Standard  makefile  for  Proto. 

#  "make"  defaults  to  NOT  compiling  the  BTRACE  code,  while  compiling  in  the 

#  Window  Manager  (NOWM  not  specified)  and  the  MONITOR  (NOMONIT  not  specified). 

#  The  output  executable  is  called  "Proto", 

0  Other  "ProtC's  are  generated  by  specifying  the  desired  executable: 

0   make  nwProto     —  defines  NOWM  and  BTRACE,  doesn't  use  Window  Manager. 

#  make  nomonProto  —  defines  NOMONIT,  lacks  MONITOR  process  and  variables. 

0   make  tlnyProto   —  defines  NOMONIT  &  NOWM.  no  Windows  &  single  user  (minimum), 

0   make  tProto     ~  like  Proto  but  also  defines  BTRACE. 

0  (use  this  Proto  for  debugging) 

0   make  all         —  makes  all  of  the  above,  one  at  a  time. 

0 

0  See   README   file  for  more  information  and  version  history 

0 

PROGRAMS  ■  Proto  nwProto  nomonProto  tinyProto  tProto ■ 

PNAME  -  Proto 

COpts  ■  -0  -I$(H0ME)/CC/src/1nclude  -DBSD 

0   The  "-I"  1s  needed  on  some  machines  that,  haven't  officially  Installed 

#  the  Concurrent  C  compiler  package.   The  "-D"  is  only  needed  because 
0   both  AT&T  and  UC  0  Berkely  consider  the  pre-defined  #def1ne  variable 

0   called  "umx"  to  be  sufficient  to  make  portable  code  possible.   Taln't  so! 

0   Thus,  in  order  to  distinguish  the  2  "standard"  systems,  I  have  created  a 

0    "ifdef  BSD"  capability  to  distinguish  BSD-unix  from  SYS5-un1x. 

0      [  The  above  is  the  private  opinion  of  the  author  and  not  his  employer.  ] 

0 

Bin  ■  $(H0ME)/bin 

0   MAN  is  directory  to  Install  the  "manl"  and  Bcat1"  directory  entries  Into. 

MAN  «  $(H0ME) 

PR  •  pr 

TERMCAP  *  -1  curses  -Itermcap 

CC  ■  4.3CCC  $(C0pts) 

SOURCE  •  netlayer.cc  I1nklayer.cc 

HEADERS  ■  proto. h  monvars.h 

OTHER  -  README  makefile 

FILES  -  $(0THER)  $(HEADERS)  $(S0URCE)  $(PNAME).1 

0    "Normal"  Proto  -  uses  "xxxN.o"  objects. 
Proto :  net  1 ayerN . o  1 1 nk 1 ayerN . o 

$(CC)  netlayerN.o  linklayerN.o  S(TERMCAP)  -o  $e 

net  1 ayerN. o:  $( HEADERS)  netlayer.cc 
$(CC)  netlayer.cc  -c 
mv  netlayer..o  netlayerN.o 

linklayerN.o:  $(HEADERS)  I1nklayer.cc 
$(CC)  11hklayer.cc  -c 
mv  1 1 nk 1 ayer . . o  1 1 nk 1 ayerN . o 

0    "No  Window"  Proto  (defines  BTRACE)  -  uses  "xxxW.o"  objects. 
nwProto:  netlayerW.o  1 InklayerW.o 

$(CC)  netlayerW.o  1 InklayerW.o  $(TERMCAP)  -o  $• 

netlayerW.o:  $(HEADERS)  netlayer.cc 

$(CC)  -DNOWM  -DBTRACE  netlayer.cc  -c 
mv  net  1 ayer.. o  netlayerW.o 

1 InklayerW.o:  S(HEADERS)  I1nklayer.cc 

$(CC)  -DNOWM  -DBTRACE  I1nklayer.cc  -c 
mv  11nklayer..o  1 InklayerW.o 

0    "No  MONITOR"  Proto  -  uses  "xxxM.o"  objects. 
nomonProto:  netlayerM. o  1 inklayerM.o 

$(CC)  netlayerM.o  1 InklayerM.o  $( TERMCAP)  -o  $» 

netlayerM.O:  $( HEADERS)  net  layer . cc 

$(CC)  -DNOMDNIT  netlayer.cc  -c 
mv  net  1 ayer.. o  netlayerM.o 
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1  inklayerM.o:    $(HEADERS)    Hnklayer.cc 

S(CC)    -DNOMONIT    11nklayer.ee   -c 
mv    11nklayer..o    1 InklayerM.o 

It    "T1ny"    Proto    (no   Windows   or   MONITOR)    -    uses    "xxxY.o"    objects. 
tlnyProto:    netlayerY.o    HnklayerY.o 

$(CC)    netlayerY.o    HnklayerY.o   $(TERMCAP)    -o   $« 

netlayerY.o:    S(HEADERS)    netlayer.cc 

$(CC)    -DNOWM   -DNOMONIT    netlayer.cc   -c 
mv   netlayer..o  netlayerY.o 

HnklayerY.o:    $(H6ADERS)    Hnklayer.cc 

$(CC)    -DNOWM   -DNOMONIT    Hnklayer.cc   -c 
mv   l1nklayer..o   HnklayerY.o 

*    "TRACE"    Proto    {used    for    debugging)    -    uses    "xxxT.o"    objects. 
tProto:    netlayerT.o    HnklayerT.o 

*(CC)    netlayerT.o    HnklayerT.o   $(TERMCAP)    -o   $» 

netlayerT.o:    S(HEADERS)    netlayer.cc 

J (CO    -DBTRACE   netlayer.cc  -c 
mv  netlayer..o  netlayerT.o 

HnklayerT.o:    $( HEADERS)    Hnklayer.cc 
$(CC)    -DBTRACE    Hnklayer.cc   -c 
mv   Hnklayer..o   HnklayerT.o 

al 1 :  $(PR0GRAMS) 

man: 

-rm  -f  man1/$(PNAME). 1  cat 1/$(PNAME) . 1 

-mkdlr  manl 

In  $(PNAME).1  man1/$(PNAME). 1 

-mkdlr  catl 

man  -M  .  $(PNAME)  >temp 

mv  temp  cat1/$(PNAME) . 1 

echo  'Manual  entries  copied  and  built.' 

prman: 

echo  'Printing  existing  man  page(s)...  use  "make  man"  to  update, 
man  -M  .  $(PNAME) 

Install:  $(PR0GRAMS)  man 

cp  $<PR0GRAMS)  $(B1n) 

(cd  $(B1n);chmod  »x  $( PROGRAMS)) 

cp   man1/$(PNAME) . 1    $(MAN)/man1/$(PNAME ) . 1 

cp    cat1/$(PNAME). 1     $(CMAN)/cat1/J(PNAME) . 1 


print : 
clean: 


J(PR)    $(FILES) 


rm   -f    *  .  [o]    a  .out 

rm   -f    man1/$(PNAME).  1    cat  1/KPNAME) .  1 

-rmdlr  manl  catl 

clobber  FRC:  clean 

rm  -f  $( PROGRAMS) 


dun  24  12:25  1987   proto . h  Page  1  App .  2-6 

/*  ProtO  HEADER  INFO.  */ 

♦ifdef  BSD 

♦include  <sgtty.h> 

♦else 

♦Include  <termio.h> 

♦Include  <sys/types .h> 

♦include  <sys/stat.h> 

♦endlf 

/*  Universal  Constants  */ 

♦define  MAXpkt  150       /*  Max.  size  of  packet  {1 rslzeof (char )- 1}  */ 
♦define  MAX! Inks  4      /*  Max.  no.  of  Links  out  of  this  node  */ 
♦define  MAXseq   7      /*  Highest  sequence  Num.  used  In  Link  Layer  */ 
♦define  NUMseq  (MAXseq+1)  /*  Number  of  different  sequence  numbers  possible  */ 
♦define  Nwlndow  (NUMseq-1)  /*  Num.  of  frames  allowed  In  "transmit"  window  */ 
/*  (This  varies  with  the  Link  Layer  protocol  - 
currently  the  "receive"  window  Is  Implicitly 
size  1  and  thus  Nwlndow  must  be  <  NUMseq)  */ 
♦define  Nbuf_req  2      /*  ♦  of  frames  on  Request  queue  1n  'foutput'  (0  to  N)V 

/*  (Doesn't  count  frames  1n  window)  */ 
♦define  MAXfr_l  (Nwindow+Nbuf_req+3+1 )  /*  Max.  frame  buffers  per  link  */ 
/*  Total  INFO  frames  queued  ■  (1/frame  in  window  +  Nbuf_req) 

Frames  in  use  by  processes  •  1  In  f Input  +  1  In  dldln  +  1  1n  dlcoln 
Frames  temporarily  used  In  foutput  ■  1 

Note: (Non-INFO  frames  are  not  held  1n  frame  buffers;  indicators  are  used 
to  send  the  frame  (e.g.,  START  Is  just  indicated  as  being  a  frame-type 
to  be  sent  when   dlcoln  requests  the  next  frame  to  send).   Thus 
foutput  needs  to  get  a  frame  buffer  and  format  It  for  these  types 
of  frames.  This  accounts  for  the  +1  count  for  foutput.   It  1s 
possible  that  frame  buffers  are  never  in  use  by  both  foutput  and 
dlcoln,  but  counting  1  extra  frame  Duffer  seems  cheap  insurance 
against  foutput/dlcoin  changes  that  might  change  that  relationship.) 

♦define  MAXbuf fared  (Nwindow+Nbuf_req) 

/*  Max.  INFO  frames  buffered  in  'foutput'  */ 
/*  «■  sum  of  INFO  frames  on  Send  and  Request  Os  */ 
♦define  FPrlor   1       /"  Priority  of  forwarded  frames  (0-hlghest)  •/ 

/*  (If  frame  priority  >  FPrlor,  no  forwarding  Is  done)  V 
♦define  UPrior  4  /*  Priority  of  new  User  packets  (<MAXbuf fered)  */ 
♦define  MINfwds  1       /*  Minimum  extra  forwarding  allowed. 

(Packets  can  be  forwarded  N  times  where 
N  Is  (the  number  of  Links  +  MINfwds))  */ 
♦define  MAXfwds   5      /*  Max.  times  a  packet  will  be  forwarded. 

(This  is  an  absolute  bound,  regardless  of  the 
number  of  Links.  There  are  other  restrictions 
imposed  In  "netlayer . cc" . )  */ 

/*  Protocol  magic  characters  -   also  affect  Escape  table  in  FT  1n1t()  */ 
♦define  EOB  char        '\252'  ~ 

♦define  S0H~char  '\253' 
♦define  ESC~char  '\254' 
♦define  BROAD  '\0'     /*  Destination  Implying  Broadcast  */ 

/*  Level  1  Protocol  Information  */ 
/*  The  following  string  tells  "openLevi*  that  Link  is  ready  */ 
♦define  CMD  END  "END-LEVl\n" 

♦define  CMD~SH  "/bin/sh"        /*  where  shell  lives  */ 
♦define  CMD_ARG  {  "bin/sh",  0  >  /*  Arg  11st  to  be  passed  to  shell  */ 

/*  Universal  Terms  */ 

♦define  OK  0 

♦define  FAIL  -1 

♦define  NC       '\0'  /*  Null  Character  */ 

♦define  PUBLIC  extern 

♦define  PRIVATE  static 

♦define  LOOP  for( j •  )  { 

♦define  ENDLDOP  > 

♦define  E0UALs(s1 , s2)  ! strcmp( s 1 . s2 )     /*  True  1f  strlngl  «■  str1ng2  */ 
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•ifndef  BSD 
•define  Index  strchr 
•define  rlndex  strrchr 
•end 1 f 

/*  Mad1f1ed  version  of  <assert.h>  */ 
•Ifdef  NDEBUG 
•define  ASSERT (EX) 
•else 
void   assert(  h 

•define  ASSERT(EX)  1f  (EX)  ;  else  assert ( "EX" ,  FILE .  LINE ) 

•end  1 f 

/*  Modified  'Plum  Hall'  version,  yields  offset  of  member  In  structure  */ 
•define  OFFSET(st,m)  ((char  ")&(((st  *)0)->m)  -  (char  *)0) 
•define  CHAR_MAX  255    /*  MAX  value  of  a  (char)  */ 

/*  Definitions  for  CH  manipulation  —  unit  of  frame  transmission  */ 
typedef  unsigned  char  CH;        /*  Should  prevent  sigh  extension  */ 
•define  CH  MAX  255  /*  MAX  value  of  a  (CH)  */ 

•define  CH~SIZE  8  /*  NumBer  of  Bits  1n  a  (CH)  */ 

•define  CH~MASK  ( ( 1«CH_SIZE  )-1 )  /*  (CH)  mask  of  1  Bits  */ 

/*  Stuff  associated  with  NOWM  and  NOMONIT  options  */ 

/*  Define  numBer  of  user  processes  (0,1,2  or  more)  for  later  use  V 
•Ifndef  NOMONIT 

•  ifdef   NOWM 

•define  XOuser   /*  Monitor  plays  user  if  (Moni tor .noWlndows)  */ 

•else 

•define  X2user   /*  Multiple  users  if  (Monitor . Windows)  "/ 

•endlf 

•else 

•ifdef  NOWM 

•define  Xluser  /*  Only  one  user  if  (noMoni tor, noWlndows)  "/ 

•else 

•define  X2user   /*  Multiple  users  if  (noMoni tor .Windows)  */ 

•endlf 

•endlf 

/*  This  stuff  is  to  allow  "wprintf"  to  look  like  fprlntf  IF  ho  Window  Manager. 
To  work,  "wprintf"  Is  replaced  by  "fprlntf". 
Also,  window-numBer  vanaBles  should  be  of  type  "WIN" 
Wopen  is  used  to  really  talk  to  the  tty.  wopen  output  goes  to  stderr. 

•Ifdef  NOWM 

•define  wprintf  fprlntf 

•define  WIN  FILE  * 

WIN  wopenO; 

WIN  Wopen( ) | 

•else 

•define  Wopen ( )  wopen ( ) 

•define  WIN  int 

•endlf 

/*  TRACE  stuff  (  on  1f  -DBTRACE  specified  &&  MONITOR  exists  */ 
•Ifdef  NOMONIT 

•define  TRACE (van, message)  /*  Null  */ 
•else  NOMONIT 
•Ifndef  BTRACE 

•define  TRACE(var .message)   /*  Null  */ 
•else  BTRACE 

•define  TRACE (var .message)  if ( FLAG( var ) )  {   wprintf  message  ;  >  else 
•endlf  BTRACE 
•endlf  NOMONIT 
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/*  Universal  Codas  */ 

enum  FalseTrue  {False*0, True) ; 

/*  The  codes  below  are  f route  ->  user,  but  share  some  values  with 
Errorcode  (see  next  enum)  */ 

enum  UError  {  U_DK»0     /*  Assumed  zero  */ 

,U_WrongState   /*  Link  already  In  requested  state  (fcontrol)  "/ 
,U~NoBuffs      /*  No  buffers  for  message  (at  this  priority)  */ 
,U_NotConn      /*  Link  not  Connected  */ 

/*  Network-layer  (f route  ->  user)  codes  follow.  */ 
,U_Term»iOO     /"  User  should  terminate  */ 

,U_NoL1nk       /*  No  Link  to  this  destination  (Unkown  dest . )  */ 
,U_NoFwd        /*  Unable  to  forward  over  the  chosen  Link  */ 
,U_Down         /*  No  operational  Link  to  destination  */ 
,U  BadArgs      /*  Bad  arguments  to  transaction  •/ 
>: 

enum  Errorcode  {  E_OK»0  /*  Assumed  zero  V 

, E_WrongState   /"  f output  ->  f route  »>  already  in  req.  state  */ 
,E_NoBuffs      /*  f wdmsg( )  ->  f route  ■>  No  buffers  for  message  */ 
,E  NotConn      /*  f wdmsg( )  ->  f route  ■>  Link  not  Connected  */ 
):" 

enum  Cntlreq  {  reqDISC,  reqCONN  }; 

enum  LlnkStates  <  L_DISC,  L_CONN.  L_wa1 tlngDISC.  L_wai t IngCONN  >; 

enum  DISCstatus  {  Dtrue,  Dfalse,  Dwa1t1ng  Jj 

/*  Universal  Types  (most  end  in  '_t'  p%r    'Plum  Hall'  */ 

typedef  enum  U_Error  UError_t; 
typedef  enum  Errorcode  Error_t; 
typedef  enum  Cntlreq  Cntl_t; 

typedef  CH  Pkt_t[];  /"  just  an  array  of  signless  char  */ 

typedef  enum  FalseTrue  BOOL; 

typedef  short  Seq_t ;  /"  Sequence  number  type  for  'f output'  */ 

/*  A11  math  on  these  is  Mod  (MAXseq+1)  */ 
/*  typedef  names  per  'Plum  Hall'  */ 
typedef  mt  metachar;  /*  Holds  a  char  or  EOF  (-1),  etc.  */ 

typedef  unsigned  int  bits;       /*  Holds  bits  for  bit  testing  */ 
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/*  Universal  Structures  V 
/*  Link  Layer  related  data  */ 


struct  Tty_struct  { 

#1fdef  BSD 

struct  sgttyb  p_data; 

struct  tchars  c_data; 

mt  d_data; 

#el se~ 

struct  termio  p_data; 

#endif 

>; 


/*  TTY  loctl()  storage  area  */ 


/*  Parnis.,  */ 
/*  chars. ,  */ 
/*    dlsdpl  ine    */ 

/*  Parameter  storage  */ 


struct  LlnkTB 
CH  1d; 


/*  Link  Table 
/* 


structure  */ 


ID  of  node  at  end  of  this  link 
'\0'  ->  Nonexistent  */ 
CH  *1ds;     /*  IDs  reachable  from  this  link  */ 
BOOL  updown;  /*  state  of  physical  link  */ 

Int  rdev.wdev;       /*  file  descr Iptor(s)  of  open  link  *7 
struct  Tty_5truct  t_save;    /*  Save  area  for  TTY  links  */ 
char  *lname;        /"  name  of  link  device  */ 
process  f output  outproc;   /*  Process  ID  of  'f output'  */ 
BOOL  G_restart;      /"  Used  by  'foutput'  and  'dlcoln'.  */ 
WIN  1;  /*  Window  used  by  Input  processes  */ 

WIN  o;  /"  Window  used  by  output  processes  */ 

struct  montbl  s  *Mvars;      /*  Points  to  MONITOR  FLAGs.  etc.  •/ 

/T  Items  used  only  by  'foutput'  appear  below,  but  are 
declared  here   so  MONITOR  can  examine  them  */ 
enum  LlnkStates  state;       /•  current  protocol  state  of  this  link  */ 

/*  Data  Transfer  protocol  Information  */ 


1nt  buffered; 


Seq_t  ExpectedF,  ExpectedA 

/*  Link  Control  protocol  information  */ 
Int  attempts; 
enum  DISCstatus  recelvedDISC; 


/*  Total  frames  buffered  in  foutput  */ 

/*  »■  sum  of  frames  on  xmit  and  Incoming  Os  "/ 

NextF; 
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/*  Link  Layer  stuff,  but  has  to  be  here  to  keep  Concurrent  C  happy. 

The  type  Act1on_t  must  be  defined  because  it  is  used  1n  the 

process  specs  for  'f output ' .etc. 
V 

/*  Frame  Buffer  -  Holds  a  Packet  ♦  control  stuff  +  Link  Layer  stuff  */ 

struct  FrameBuf  { 

bits  con;    /*  Control  bits  for  frame  management  -  NEVER  xmitted  */ 

/*  Beginning  of  transmitted  frame  */ 
CH  seq;      /*  Frame  Type  (Sequence  number  embedded  for  INFO  frames)  */ 
CH  ack;      /*  Piggybacked  ACK  seq.  0    '/ 
CH  len;      /*  Does  not  count  checksum  */ 
CH  from;     /*  Originator  of  data  */ 
CH  to;       /*  Destination  of  data  */ 

CH  net_type;  /""  Network  layer  use  only,  has  count  and  userlD   */ 
CH  packet[MAXpkt];   /*  Network  data  */ 
/*  Space  below  is  not  strictly  part  of  Frame,  but  holds  intermediate  data  */ 
CH  crcx[2];  /'*  Reserve  space  for  cksum  (needed  for  MAX  sized  packets)  */ 

typedef  struct  FrameBuf  Fbuf; 

enum  Action  (  /*  What  to  do  with  Frame  */ 

A_IGNORE       /*  foutput  ->  finput  ■>  ignore  frame  •/ 

,A~ROUTEMSG     /*  foutput  ->  finput  =>  forward  to  Router  */ 

.A  BADframe     /*  foutput  ->  finput  ■>  foutput  detected  error  */ 
}; 

typedef  enum  Action  Act1on_t; 

/"  Process  specs  for  NET/LINK  LAYER  Interface  */ 

process  spec 

froute(CH  node_1d, process  rcvuser  Rcvuser, 

struct  LinkTB  *L1nktable) 
< 

trans  void  forwardmsg( Int  Llnk.Pkt_t  Pkt.CH  From, 

CH  To.CH  Len,  CH  Net_type);  /•  finput  */ 

trans  UError  t  f sendmsg(Pkt_t  pkt, 

CH  to.CH  len.  Int  userlD);  /*  user  */ 

trans  UError_t  f control (Cntl_t  req.CH  dest);        /*  user  */ 

process  spec 

foutput(CH  l1nk_node,  Int  outdev.  struct  LinkTB  *Lp,  process  service  Serv) 

trans  Fbuf  *framereq();  /*  dlcoin  */ 

trans  Error_t  fwdmsg(int  Priority. Pkt  t  pkt.CH  from, 

CH  to.CH  len.CH  net_type);  /*  f route  */ 

trans  Error_t  fctrl(Cntl_t  req);  /*  f route  */ 

trans  Act1on_t  framein(Fbuf  *fr);  /*  finput  */ 

trans  void  ft1me();  /*  f timer  */ 

process  spec 

finput(CH  my_node,1nt  indev.CH  1 Inkno. process  foutput  Outproc, 

process  froute  Router .process  service  Serv. struct  LinkTB  *Lp); 
process  spec 
service(int  numFrames) 
< 

trans  Fbuf  *getF(); 

trans  void  relF(Fbuf  *fr); 
}; 

/*  List  returned  values  of  some  non-(1nt)()  system  functions.  */ 
char  *memcpy( ) ; 
void  f ree( ) ; 
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#ifndef  nomonit 

♦define  MONPTR  MONPTR_not_def  ined 

*def1ne  FLAG(var)  MONPTR  var .  flag 

#def1ne  COUNT(var)  (MONPTR  var._count  + 

#def1ne  PICTUREfvar .value)  (MONPTR  var.  picture  -  (im)value) 

struct  flag  {char  *  p;1nt  _flag;};   ~ 

struct  count  (char  w_p ; 1 nt~_count ; > ; 

struct  picture  (char~*_p; int  _p1cture;}: 


/*  MUST  be  re'deflne'd  in  each  module  "/ 
1) 


struct  monentry_s  { 

char  *str: 

1nt  datum; 
>: 

#else  NOMONIT 
#def ine  FLAG(var) 
*def1ne  COUNT (var) 
♦define  PICTURE(var. value) 
#endif  NOMONIT 


/*  Structure  of  a  single  entry  1n  MONvars  structures  •/ 
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/*  See  README  file  for  Info  on  "Proto"  */ 

# include  <ctype.h> 

^include  <std1o.h> 

#1nclude  <str1ng.h> 

^include  <errno.h> 

# Include  <fcntl .h> 

#1fndef  NOWM 

# include  <ccwm.h> 

#endlf 

# 1 ncl ude  "proto . h" 

#  1  nc  1 ude  "monvars . h " 

/*  Def Ines,  Enums ,  etc.  */ 

#define  CNTLd  '\004'   /*  Control -D  character  •/ 

#def1ne  M0N_md         '--'      /*  Indicates  MONITOR  command  if  first  char.  */ 

/*  Next  3  Items  define  contents  of  "net_type"  in  the  transmitted  Frame  */ 
#define  cntMSK  070      /*  Mask  of  number  of  times  this  Packet  was  forwarded  */ 

/*  (NOTE:  this  limits  "MAXfwds"  in  'proto. h'  to  7)  */ 
#define  cntINC  010      /*  1  1n  the  low  bit  position  of  cntMSK  */ 
#define  uIDMSK  007      /*  ID  of  originating  user  at  node  "from"   */ 

/*  Status  returns,  etc.  (enum  used  as  a  CONST  mechanism)  */ 
enum  RouteCode  {  R_Down  ■  -3     /*  Link  1s  down  •/ 

,R_BadDest  «  -2         /*  Dest  unknown  or  wierd  "/ 
,R  ThlsNode  -  -1        /*  Dest  1s  this  Node  V 
,R  LO  «  0  /*  Route  to  Link  0  */ 

/*    CAUTION:  Values  R  LO  to  MAXseq  are  used  */ 
/*   to  indicate  'Rout  to  Link  n' .         */ 

typedef  enum  RouteCode  Route_t; 

/*  Magic  file  descriptors  that  /bln/sh  and  loctl()  expect  */ 
/*  (Used  by  "malnO"  and  HopenLev1()"  and  others.  )  */ 

^define  STDIN  0 

#define  STDOUT  1 

#define  STDERR  2 

/*  PROCESS  SPECIFICATIONS  —  Network  Layer  */ 

/*  process  spec  for  froute  is  in  proto. h  */ 
process  spec 
user(process  froute  Route,  CH  nodelD,  Int  userlD); 

process  spec 
rcvuser( ) 

{       /*  Accepts  frecelvemsg  request  from  flnput,      */ 
/*  does  whatever  users  do  with  packets.  */ 

trans  void  f rece1vemsg(Pkt_t  pkt.CH  from, 

CH  to.CH  Ten, int  userlD); 

rfifndef  NOMONIT 

process  spec 

M0NIT0R(process  froute  Route,  CH  nodelD,  WIN  window); 

#endif  NOMONIT 
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/*  GLOBALS  */ 

CH  NodelD;      /*  My  name's  name  */ 
CH  *NodeIDs;     /*  All  my  nicknames  */ 
struct  LlnkTB  Llnktable[MAX1 inks] ; 

process  anytype  G_malnp1d;      /*  Used  to  abort  everything  */ 
WIN  G  malnwindow;  /*  Used  as  the  "operator's  console"  */ 

/*  1f  NOWM,  ■  the  tty's  FILE  *   */ 
/*         or  a  real  file  if  'r'  flag  */ 
char  *G_argvO;  /*  Pointer  to  program's  name  */ 

BOOL  G_flagr;  /*  True  Iff  '-r'  was  1n  argv[1]  */ 

1nt  G_maxfwds;  /*  Computed  Max.  forwarding  for  any  packet  */ 

struct  Tty_struct  G_savearea;    /*  user's  TTY  1octl()  storage  */ 

PUBLIC  mt  errno; 

/•  MONITOR  variables  for  the  Network  Layer  */ 

#ifndef  NOMONIT 

#undef  MONPTR   /*  define  access  to  MONITOR  "trace"  variables  */ 

#def1ne  MONPTR  M0N_TBL .         /*  Used  by  all  Network  Layer  */ 

#def1ne  F(var)  struct  flag  var; 

#def1ne  C(var)  struct  count  var; 

#def1ne  P(var)  struct  picture  var; 

PRIVATE  struct  montbl  s  {  /*  MONITOR  variables  */ 

#1fdef  BTRACE   /"  Only  define  1f  TRACE  expands!  */ 

F(rtrace)  /*  1  to  TRACE  f route( )  process  "/ 

#end1f 

char  *_p; 
#undef  F 
#undef  C 
#undef  P 

#def1ne  F(var)  {"var",0). 
#def1ne  Fset(var)  {"var",1), 
#def1ne  C(var)  {"varutO}, 
#def1ne  P(var)  {"var",0>, 
>  M0N_TBL  •  { 
/Mfdef  BTRACE   /*  Only  define  If  TRACE  expands!  */ 

Fset(rtrace) 
#end1f 

(char  *)0 
>: 

#undef  F 
#undef  C 
#undef  P 

#end1f  NOMONIT 
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/*  FUNCTIONS  (Common  to  Net  and  Link  Layer)  */ 


#ifdef  NOWM 

WIN 

WopenO  {  return  G_ma 1 nw 1 ndow ;  > 


wopen()  <  return  stderr;  } 
#end1f 

void 

rest_tty(f d,  savearea) 
1nt  fd;  struct  Tty_struct  "savearea; 


/*  returns  a  tty  file  desc.  */ 
eturns  non-W1ndow  file  desc.  */ 


{ 

#1fdef  BSD 

1octl (fd, 
1octl(fd, 
1octl (fd, 

yfelse 

loctKfd, 

#endlf 

> 


/*  Restore  TTY  state  */ 


TIOCSETD, 
TIOCSETP, 
TIOCSETC. 


&savearea->d_data) ; 
&savearea->p_data) ; 
&savearea->c  data); 


TCSETAW,  &savearea->p_data); 


/*  Restore  dlsdpl  .  . 

/*  tty  parms . ,  */ 

/*  tty  chars.  */ 

/*  Restore  parms.  */ 


void 

save_t ty ( f d ,  savearea ) 
Int  fd;  struct  Tty  struct  "savearea; 

{  /•  Save  TTY  params  */ 

#1fdef  BSD 

loctl (fd,  TIOCGETD.  &savearea->d_data) 
loctKfd,  TIOCGETP.  &savearea->p_data) 
loctKfd,    TIOCGETC,    &savearea->c   data) 

#else 

loctKfd,  TCGETA,  &savearea->p  data): 

#end1f 

) 

void 

raw_t ty ( f d ,  savearea ) 

1nt  fd;  struct  Tty_struct  "savearea; 
<  /*  Attempt  to  set  fd  to  "raw"  I/O   */ 

struct  Tty_struct  local  area; 

/*  First,  save  data,  then  save  locally 
save_tty(f d,  savearea) ; 
save~tty(fd,  fclocalarea) ; 
#1fdef  BSD 

localarea.d  data  =  OTTYDISC; 
loctKfd,  TIOCSETD,  &localarea.d_data); 
localarea.p  data. sg_f lags  |»  (RAW |TANDEM) ; 
local  area. p_data.sg  flags  &»  ~(ECH0 |CRM0D) 
TIOCSETP.  Slocalarea.p  data); 
_data. t_startc  ■  '\021'; 
_data. t_stopc  «  '\023'; 
TIOCSETC,  &localarea.c  data); 


/*  Save  dlsdpl  . ,  •/ 

/•  tty  parms. .  */ 

/*  tty  chars.  */ 

/*  Save  for  restore,  */ 


modify  and  set  raw.  */ 


/*  Set  "old"  dlsdpl.,  */ 


/*  tty  parms. 


*/ 


/*  tty  chars.  */ 


loctKfd, 

local  area. 

local  area. 

loctKfd. 
#else 

localarea.p_data.c_of lag  ■  O; 

lOCalarea.p_data.c_1f  lag  -  (ISTRIP  |  BRKINT  |  IGNPAR  J  IXOFF  I  IXON); 

localarea.p_data.c_lf  lag  &»  ~(ICANON  |  ECHO);        /■  "Raw"  */ 

localarea.p_data.c_cc[0]  ■  5; 

localarea.p_data.c_cc[ 1 ]  B  5; 

local  area. p~data . c~cc[4]  «  1 ; 

localarea.p_data.c_cc[5]  ■  100;      /*  10  seconds  to  timeout  read()  */ 

1octl(fd,  TCSETAW,  Slocalarea.p  data);       /*  Save  for  restore.  "7 
#end1f 
) 

void 

endProto(code)  int  code; 

< 

1f(  G_flagr  ■»  True  )  f f lush(G_mainw1ndow) ; 


Jun  25  05:11  1987   net  1 ayer . cc  Page  4  App .  2-15 

delay  2;        /*  Walt  for  output  Puffers  to  empty  */ 

c_abort(G_ma1np1d) ; 

rest  tty(STDOUT,  G_savearea); 

exl tTcode) : 

) 

void 

errmsg(msg.code)  char  *msg;  1nt  code; 

wprlntf  ( G_ma 1 nw 1 ndow , H\n%s:  code  »  %d,  errno  *  %d\nu .msg.code.errno) ; 

fprintf (stderr, "\n%s:  code  -  %d,  errno  *  %d\n" .msg.code.errno) ; 

1f{  G_flagr  «  True  )  f f lush(G_ma1nw1ndow) j 

delay  2;        /*  Walt  for  output  Puffers  to  empty  */ 

c_abort(G_malnpld) ; 

rest_tty(STDOUT,  q   savearea); 

endProto(8) ; 

/*  Modified  versions  of  assert. c   1.2    */ 
*      called  from  "ASSERT"  macro;  prints  like  'errmsgO'  does 

#def1ne  WRITECs.  n)      WRITESTR(s.n. ■" ) 

#define  WRITESTR(s1.  n.  s2)      C  wprlntf  (G  mainwlndow, *%, *■%■" ,n,s1 ,s2) ,  \ 

fprintf (stderr, "%. *s%s" , n. s1 , s2)  ) 
void 

assert (assertion,  f 1 lename,  1 ine  num) 
char  'assertion; 
char  *f 1 lename; 
1nt  1 ine  num; 
< 

static  char  11nestr[]  ■  ",  Una  NNNNN\n"; 

register  char  *p  ■  &linestr[7]; 

register  1nt  div,  digit; 

WRITESTR( "Assertion  failed:  ",  18.  assertion); 

WRITESTRC,  file  ",  7,  filename); 

for  (d1v  ■  10000;  div  )■  0;  line  num  %-  div.  div  /»  10) 

1f  ((digit  -  1 1ne_num/d1v)  !■  0  ||  p  !■  &Hnestr[7]  ||  d1v  =-  1) 
*p++  »  digit  +  '0' ; 
*p++  »  '\n'; 
*p  -  '\0'; 

WRITE (1 inestr,  (unsigned)  strlenO inestr)); 
rest_tty(STDOUT,  G  savearea); 
(void)  abort(); 


Jun  25  05:11  1987   netlayer.cc  Page  5  App.  2-16 

/*  FUNCTIONS  (Network  Layer  only)  */ 
PRIVATE  Int 

wgetl ine(w1ndow.buf .maxsize) 
register  WIN  window;  register  int  maxsize; char  *buf  ; 

register  int  ch; 
register  char  *cp  ■  buf ; 
do  { 
#lfndef  NOWM 

*cp++  «  ch  ■  wgetchar(window) ; 


-else 
#end1f 


*cp++  ■  ch  *  getc( window) ; 

} 

while  (   — maxsize  >  0  &&  ch  !■  '\n'  &&  ch  !«  EOF   ); 

*cp  ■  NC;  /*  Always  terminate  string  after  V 

/*  last  ch  was  written.  */ 

if  (ch  »■  EOF)  return  0;  else  return  cp-buf ;   /*  ■  string  length*/ 
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/*  Open  a  Physical  (Layer  1)  channel.  */ 
/*  Returns  file  descriptors  In  f d[ 3 .  */ 

/*  First,  a  process  that  1s  used  as  a  "reader"  child  In 

opening  a  Level  1  channel.   It's  not  pretty  but  ... 
*/ 
process  spec  read_proc(  int  1n_fd,  WIN  out_w1n,  BOOL  *flag); 

process  body  read_proc( 1n_f d.  out_w1n,  flag)  { 
register  int  re; 

char  buf[4];        /*  Only  uses  Ouf[0]  so  far...  */ 
do  { 

re  ■  read!  in  fd,  buf .  1); 
1f(rc  <  0)  <" 

wpr 1ntf (out_w1n, "Read  1n  'read_proc'  falls"); 
return; 
} 

wpr1ntf(out  win. "%c" .buf [0] ) ; 
>  while  ('flag  "  False); 
return:      /*  Terminates  process  */ 

PRIVATE  char  *cmdargsv[ ]  =  CMD  ARG; 
PRIVATE  BOOL  abort_flg; 

PRIVATE  int 

openLevI (name.fd. Instream.outstream. 1  Ink) 
char  "name;  int  fd[2);  WIN  mstream;  WIN  outstream;  1nt  link; 

int  sv[2],  fdtemp,  ret; 

struct  Tty_struct  *ttyp;     /*  ptr.  to  TTY  save  area  for  link  */ 

char  *cp: 

Int  p1pe2parent[2).  pipe2ch1 ld[2] ;   /*  2  pipes  for  "cmd"  mode  */ 

mt  p1d;  /•  pid  of  child  for  "cmd"  */ 

char  buf  [200]; 

1nt  cnt; 

ttyp  -  &L1nktable[l ink] .t_save; 

1f(  EOUALs(name, "pipe")  ){   /*  Software  loop-around  V 
ret  ■  plpe(sv); 

1f(  ret  <   0  )  errmsg( "openLevI :pipe  fail  1",ret);/*  Aborts  everythlna  */ 
fd[0]  -  sv[0]; 
fd[1]  ■  sv[1); 
return  OK; 
) 

1f(  EOUALs(name, "tty")  )  <   /*  Use  STOIN.STDOUT  as  channel  */ 
1f(  G_flagr  »»  False  ) 

errmsg( "openLevi :  'tty'  used  without  '-r'  option". 0); 
fd[0]  -  STDIN; 
fd[1]  -  STDOUT; 

raw_tty(fd[1],  ttyp):    /*  Attempt  raw  I/O  Interface  */ 
return  OK; 
) 

1f  (  EOUALs(name."cmd")  )  {  /*  Invoke  -/btn/sh"  to  define  link  */ 
ret  -  p1pe(pipe2parent) ; 

if(  ret  <  0  )  errmsg( "openLevI ;cmd  fall  1",ret);  /*  Aborts  everything  */ 
ret  -  pipe(p1pe2child); 

1f(  ret  <  0  )  errmsg( "openLevI : cmd  fan  2". ret);  /*  Aborts  evervthlno  */ 
1f(  (  ptd  -  fork()  )  <  0) 

errmsg( "openLevI : cmd  fall  3", pid);  /*  Fork  failure  */ 

if(  pid  «  0  )  {        /*  The  child  executes  this  code  */ 
close(STOIN);close( STDOUT ); cl ose( STDERR  ) ; 

/'  Open  STDIN  so  that  It  reads  pipe2chi  ld[  1  ]  */ 
1f(  (fdtemp  •  dup(p1pe2chi ld[01)  )  I"  STDIN  ) 
errmsg( "openLevi :cmd  fall  4", fdtemp); 

/   Open  STDOUT  and  STDERR  to  write  to  p1pe2parent [0]  */ 
1f(  (fdtemp  ■  dup(pipe2parent[ 1 ] )  )  !■  STDOUT  ) 

errmsg( "openLevI ;cmd  fall  5",fdtemp); 
1f(  (fdtemp  ■  dup(p1pe2parent[1])  )  !■  STDERR  ) 
errmsg( "openLevI :cmd  fail  6", fdtemp); 
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/*  Close  the  extraneous  file  descriptors  */ 
close(p1pe2ch1 ld[0]);  close(p1pe2ch1 ld[ 1 ] ) ; 
close(pipe2parent[0j ) ;  close(pipe2parent[ 1  ] ) ; 
execve(CMD_SH,cmdargsv,0) ; 
exlt(0201)T  /     Tell  parent  execve  failed  */ 

) 

/*  The  parent  executes  this  section  */ 

else  { 

close(p1pe2parent[ 1 ] ) : 

close(pipe2chl l d[0] ) ; 

fd[0]  -  p1pe2parent[0];  /*  Link  will  use  these  fd's  for  */ 

fd[l]  *  p1pe2chlld[1];    /*  I/O  to  "and"  •/ 

wprlntf (outstream, "Enter  commands  to  setup  Link  %d:".11nk); 

/*  Now  create  a  Concurrent  C  process  to  read  fd[0]  (response  from  the 
CM0_SH  UNIX  process)  and  write  to  "outstream"  (so  user  can  see  1t). 
This  continues  until  the  process  terminates,  meaning  the  link  should 
be  "up" . 


V 


abort_f1g  -  False;   /•  True  If  read_proc  should  terminate  */ 
create  read  proc( fd[0] , outstream, fiabort  fig); 
fort:;)    i     ~ 

cnt  ■  wgetl 1ne( Instream.buf . slzeof  buf); 

1f(cnt  <■  0)  errmsg( "openLevi :cmd  fail  7", cnt); 

1f(  EGUALs(buf ,CMD_END)  )   break;        /*  Link  is  up  "/ 

wrlte(fd[ 1] ,buf .cnt);    /*  Send  input  to  child  V 
/*  dust-created  child  reads  Input  side,  writes  to  outstream.  */ 

abort_flg  ■  True; 

return  OK; 
> 
} 

/*  Not  a  special  name,  so  "name"  must  be  a  device  or  f11e  */ 

/*  In  particular,  the  "name"  could  be  of  the  form  "dev in, devout"  */ 

/*  First  determine  which  form  was  used.  */ 

1f  (  (cp  «  1ndex(name, ' , ' ))  «  NULL)  {      /*  Single  "name"  form  */ 

ret  ■  open ( name, 0_RDWR) ; ; 

if(  ret  <  0  )  errmsg( "openLevi : 'dev'  fail  1",ret);/*  Aborts  all  "/ 

fd[0]  ■  ret; 

fdt 1]  -  ret; 

raw_tty(fd[1] .  ttyp);    /*  Attempt  raw  I/O  interface  */ 

return  OK; 
}  else  {  /*  "devin, devout"  form,  open  both  devices/files  */ 

*cp++  ■  NC;      /*  Changes  ','  to  '\0'  and  points  to  "devout"  */ 

ret  ■  open ( name, 0_R00NLY) ; ; 

1f(  ret  <  0  )  errmsg( "openLevi : 'devin'  fail  1",ret);/*  Aborts  all  */ 

fd[0]  «  ret; 

ret  »  open(cp,0_WRONLY);         /*  "cp"  points  to  "devout"  */ 

1f(  ret  <  0  )  errmsg( "openLevi : 'devout'  fail  1",ret);/*  Aborts  all  */ 

fd[1]  »  ret; 

raw_tty(fd[1],  ttyp);    /*  Attempt  raw  I/O  "write"  Interface  */ 

return  OK; 
> 


/*  Simple-minded  routing  scheme  for  Network  Layer.   If  "to"  1s  In  NodelDS. 
the  routing  1s  to  ThlsNode.   Otherwise,  look  for  a  Link  that  has  "to"  as 
the  ID  at  the  other  end  of  the  Link.   Failing  that,  look  for  the  first 
Link  that  has  "to"  1n  It's  "ids"  string.   The  "dest_found"  variable  is 
only  to  determine  if  "to"  wasn't  found  at  all  (False)  or  was   found  only 
on  Links  that  were  "down"  (True).   "Iast_d1tch"  is  used  to  try  all 
routes  to  "to"  that  don't  involve  "1nl1nk"  before  routing  back  over  the 
Incoming  Link. 

NOTE:  "to"  «  "from"  where  "inlink"  1s  >■  0  (message  1n  over  a  link) 
1s  considered  a  BadDest  (because  the  current  implementation  of  Proto 
won't  ever  send  a  message  out  that's  destined  for  itself),  but  this  could 
be  changed  if  1t  was  useful  for  verifying  routing  at  the  other  end 
of  a  Link  or  whatever....?? 
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V 
PRIVATE  1nt 
nxt_L1nk( 1nl Ink, f rom, to)  Int  1n1 Ink; register  CH  from, to; 

register  LlnkTB  *p; 

register  1nt  llnkno,  dest  found  ■  0,     /*  counts  times  "to"  found  */ 

last_ditch  -  0;  /*  counts  1 1nkno«1nl  Ink  */ 

register  char  *cp; 

1f  (to  =»  NC)  return  R_BadDest; 

~  /*  Broadcast  routing  not  Implemented!  */ 
if  (to  «  from  &&  Inllnk  >=  0) 

return  R_BadDest;    /*  See  NOTE  above...  */ 
cp  ■  NodelDs; 

while(  *cp  !■  NC  &&  *cp  !■  to  )  cp++;    /*  Is  "to"  1n  NodelDs  */ 
1f(  *cp  !-  NC  )  return  R_Th1sNode;       /*  Return  If  it  is.  V 

/*  Search  Linktable  for  direct  path  to  "to"  */ 
for(  p  »  Linktable,  linkno  ■  0;  llnkno  <  MAXllnks;  1 1nkno++ ,p++)  { 
1f(  p->1d  «»  to  )  { 
dest_found++; 
1f(  p->state  !■  L_C0NN  &&  p->state  !«  L_wai t i ngDISC  ) 

continue;  /*  Ignore  un-useable  links  */ 

1f(  p->updown  «  False) 

continue;  /*  Ignore  un-useable  links  */ 

if (  inllnk  «-  1 inkno  ) 

last_d1tch++;        /*  Inc.  match  count  */ 
else 

return  (Route_t )1 inkno;     /*  Return,  link  1s  UP.  */ 

> 

/*  Falls  through  1f  no  direct  link  to  "to"  1s  UP,  or 

the  only  direct  link  was  the  incoming  link  ( last_d1 tch++)  */ 

/*  Search  Linktable  for  Indirect  path  to  "to"  "/ 
for(  p  *    Linktable,  linkno  -  0;  llnkno  <  MAXllnks;  1 1nkno++ ,p++)  { 
cp  ■  p->1ds; 

while(  *cp  !«  NC  &&    *cp  !•  to  )  cp+*;        /*  Is  "to"  in  "Ids"?  */ 
if(  "cp  !«  NC  )  { 
dest_f ound++; 

lf(  p->state  !-  L_C0NN  &&  p->state  !-  L_walt1ngDISC  ) 
continue;  /*  Ignore  un-useable  links  */ 

1f(  p->updown  ■■  False) 

continue;  /*  Ignore  un-useable  links  */ 

1f(  Inllnk  «  linkno  ) 

last_ditch++;        /*  Inc.  match  count  */ 
el  se 

return  (Route_t)l Inkno;      /*  Return,  found  an  UP  link  */ 

} 

1f(  last_ditch  !-  0  ) 

return  (Route  t)1nlink;      /*  inllnk  was  only  UP  link  avail.  */ 
1f(  dest_found  ) 

return  R_Down;  /*  No  Link  UP  to  "to"  */ 

return  R_BadDest;  /*  or  No  such  "to"  destination  */ 

/*  Attempts  to  find  an  UP  Link  to  "to".   Basically  the  same  technique 
as  above.   However,  could  be  enhanced  to  handle  DOWN  Links  by 
adding  new  types  of  "req"  requests,  such  as  "reqUP" 

PRIVATE  1nt 

contro!_L1nk{req, to)  Cntl_t  req;  register  CH  to; 

register  LlnkTB  *p; 

register  Int  linkno,  dest_found  ■  0;     /*  counts  times  "to"  found  V 

if  (to  -»  NC)  return  R_BadDest; 

1f(req  !=  reqDISC  &S  req  !«  reqCONN)  return  R_BadDest ; 
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/*  Search  Linktable  for  direct  path  to  "to"  */ 
for(  p  ■  Linktable,  linkno  «  0;  1 inkno  <  MAXlinks;  1 inkno++ ,p++)  { 
1f(  p->id  «  to  )  { 
dest_found++; 
if(  p->updown  «  True) 

return  (Route  t)l Inkno;      /*  Return  1f  link  1s  UP.  */ 
> 
> 

/*  Indirect  paths   are  not  searched  for,  since  we 
can  only  do  "control"  requests  on  links  we're 
directly  connected  "to".  */ 
1f(  dest_found  ) 

return  R_Down;  /*  No  Link  UP  to  "to"  */ 

return  R_BadDest:  /*  or  No  such  "to"  destination  */ 


PRIVATE  UError_t 

do_user ( cp ,  1  en ,  win.  Router ,  nodelD ,  user ID ) 
char  *cp;  int  len;  WIN  win;  process  froute  Router;  CH  nodelD;  1nt  userlD; 
{ 

register  char  dest ; 

UError_t  rcode; 

/*  Only  do_user()  uses  (so  far)  of  win  and  nodelD  are  in  TRACE  statements.  */ 
/*  CC  says  "not  referenced"  1f  TRACE  is  turned  off.  so  here's  references  */ 
w1n»win;  nodeID«nodeID;      /*  (should  not  generate  code)  */ 

/*  Dest  1s  first  char  of  Input.   Special  cases  are: 

ien  <■  o  implies  EOF,  assume  user  wants  to  terminate 

'/'   —  user  wants  to  terminate  (  '//'  will  terminate  Proto  itself) 

—  broadcast  message  (dest  »  l\0* ) 

—  disconnect  a  link 

—  connect  a  1  Ink 


V 


1f  (  len  <■  0  )  return  U  Term; 

1f  (  len  >  MAXpkt+1  )  len  ■  MAXpkt+1;        /*  Ignore  excessive  data  */ 

dest  ■  "cp;  /*  Get  initial  character.  */ 

/*  Ignore  lines  that  are  empty  or  start  with  a  Blank.  */ 
if  (  dest  ••  '\n'  ||  dest  ■»  '  '  )  return  U  OK; 
If  (  dest  ■»  '/')  < 

1f(  len  >  1  &&  *(cp+1)  «  '/'  )  endProto(O); 
else  return  U  Term;      /*  user  wants  to  die  alone.  */ 
> 
if  (  dest  ■■  '-')  {         /*  Disconnect  request  */ 

if  (  (rcode  ■  Router . f control (reqDISC, *(cp+1 )) )  !-  U_0K  ) 

TRACE(rtrace,(w1n, "%c   Unable  to  dlsconnectli  code«%d\n", 
*(cp+1 ) .rcode)); 
return  rcode; 
> 
If  (  dest  ■-  '+')  {         /*  Connect  request  */ 

if  (  (rcode  -  Router . f control ( reqCONN, ""(cp+1 )) )  !■  U_0K  ) 
TRACE(rtrace, (win, "%c   Unable  to  connect!!  code»%d\n", 
*(cp+1), rcode)); 
return  rcode; 
> 

/*  Else  none  of  the  above,  so  Send  a  packet  */ 
If  (  dest  ■«  '*')  dest  *  BROAD;      /*  Dest  '*'  1s  broadcast.  */ 
1«n — ;  /*  Adjust  length  for  removal  of  "dest*    */ 

rcode  «  Router . fsendmsg(  (Pkt_t )(cp+ 1 ) ,  (CH)dest,  (CH)len,  userlD); 
1f  (rcode  !-  U_0K) 

TRACE(rtrace, (win, "Node  %c:    Can't  send  message  to  %c   -   code-%d\n". 
nodel D , dest , rcode ) ) ; 
return  rcode; 
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#ifndef  N0M0NIT 


PRIVATE  void 

dmp  monvarstmtb! , win)  struct  montbl  s  'mtbl ;  WIN  win; 

< 

register  struct  monentry_s  *p; 

for(  p  ■  (struct  monentry_s  "jmtbl;  p->str  !■  (char  *)0;  p++)  { 
wprlntf  (win."  %s  ■  %d\nH ,p->str ,p->datum) ; 

} 
> 

PRIVATE  struct  monentry_s  * 

find  monvar(name,mtb1 , wTn)  char  *name;  struct  montbl  s  *mtbl ;  WIN  win; 

register  struct  monentry_s  *p; 

f or(p»(struct  monentry_s  *)mtbl;  p->str  !■  (char  *)0;  p++)  { 
1f (  strcmp(p->str,name)   ■■  0)  return(p) ; 

wprlntf  (win,"  %s  not  1n  Mvar  table!\n" , name) : 
return(  (struct  monentry_s  *)0  ); 

PRIVATE  void 

do_moni tor(cp.  Ten,  win,  nodelD) 

char  *cp;  int  len;  WIN  win;  CH  nodelD; 
{ 

char  1 Inebuf [256] ;   /*  For  monitor  input  */ 

struct  montbl_s  "mtbl ; 

struct  monentry_s  *ep; 

register  LinkTB-*Lp; 

register  int  1 1nkno; 

char  *p, com. "name; 

swltch('cp)  {        /*  First  char  is  type  of  MONITOR  command  */ 

case  ' X ' : 

errmsg(  "MONITOR  Hard  ExIf.O); 
break ; 

case  '\n':        /*  Ignore  empty  lines  */ 

case  '  '  :         /"  . . .  and  those  starting  with  Blank  */ 

break; 
case  'M':  /*  Input  in  MONITOR  mode,  examine  MONvars  */ 

1f(len  I-  3)  {   /•  Men"  Includes  trailing  '\n'  */ 

wprlntf  (win,  "'Mx'  command  needs  'x'  ■  NodelD  or  L1nkI0\n"); 
return; 
} 
/*  Set  "mtbl "  to  the  requested  table  of  MONvars  */ 
1f(  (CH)*(cp*1)  --  nodelD  ) 

mtbl  •  &M0N_TBL;  /*  If  'x'  is  this  Node...  */ 

else  {  /*  ...else  search  for  It.  */ 

for(Lp  ■  Llnktable.l 1nkno  =  0;  linkno  <  MAXllnks;  1 1nkno++, Lp++)  { 
1f(Lp->1d  —  (CH)*(cp+D)  break;        /*  stop  if  found  */ 

if(  linkno  >»  MAXlinks  )  {   /*  Indicates  not  found  */ 
wprlntf  (win,  ■ 'Mx'  command  :  Link  'x'  unknown\n" ) ; 
return; 

> 

mtbl  ■  Lp->Mvars; 
> 

/*  "mtbl"  now  set,  so  retrieve  reqests  for  what  to  do  with  it.  */ 

LOOP  /*  Exit  with  a  '0'  command  */ 

wprlntf  (win, "Enter  command:  "); 
/*  Read  from  screen  */ 

len  »  wgetl 1ne(w1n,  1 inebuf,  sizeof  1 inebuf); 
if (len  «  0)  return; 
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p  ■  1 1  nebuf  ; 
com  ■  *p++; 

1f(com  mm    '\0')  return; 
whi le(  isspace{ *p)  )  p++; 
name  ■  p; 

while(  Msspace(*p)  )  p++; 
"P  -  '\0'; 
sw1tch((mt)com)  { 
case  'd' : 

1f(  *name  «  '\0')  { 

dmp  monvars(mtbl , win) ; 
) 
else  { 

1f(  (ep  ■  f ind_monvar( name, mtbl , win)) 

mm    (struct  monentry_s  *)0  )  break; 
wprlntf  (win,"  %s  -  %d\n" ,name,ep->datum) ; 

break; 

case  'r':  ;    /*  These  two  are  soooo  similar!  */ 
case  's' : 

If ("name  «  '\0' )  { 

wprlntf  (win,  "ERR:  Must  supply  an  Mvar  narneAn"); 
break; 
} 
1f(  (ep  »  f 1nd_monvar( name, mtbl , win)) 

«  (struct  monentry_s  *)0  )  break; 
1f (com  «■  'r' )  { 
ep->datum  ■  0: 
wprlntf  (win,"  %s  reset\n" .name) ; 

else  { 

ep->datum  ■  1 ; 

wprlntf  (win,"  %s    set\n" .name) ; 

break; 

case  '0' : 
return; 

default: 

wprlntf (win, "%s  not  a  command — try ;\n" .name) ; 
wprlntf (win, "s  monvar  -  set  monitor  varlab1e\n" ) j 
wprlntf (win, "r  monvar  -  reset  monitor  var1able\n" ) ; 
wprlntf (win, "d  monvar  -  dump  monitor  var1able\n" ) ■ 
wprlntf (win. "d  -  dump  all  monitor  var1ables\n" ) ; 
wprlntf (win. "0  -  exit  Monvar  mode\n"); 

>       /*  end  of  "switch  (com)"  and  "case  'M'"  */ 
ENDL00P 

def au 1 t : 

wprlntf  (win,  "Unlmplemented:  %s\n",cp); 
break; 
> 
) 
#end1f  N0M0NIT 
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void 

main(argcargv) 

Int  argc;char  **argv; 

/*  Executed  by:   Proto  [-r]  N1ds  [Ids, dev]  ... 

where:  N1ds  -  characters  (printable  ASCII)  identifying  this  node. 

(First  character  is  the  Node  Name,  others  are  "nicknames".) 
Ids   -  characters  (printable  ASCII)  identifying  nodes  at  the 
other  end  of  the  preceding  "dev".  (','  not  allowed) 
(First  character  is  the  Node  at  other  end  of  "dev", 
others  are  nodes  "reachable"  from  that  Node.) 
dev  -  communication  device  name  (e.g.,  M/dev/tty18H ) 

or  special  name  (e.g.,  "pipe"  or  "tty"  or  "cmd"). 

1 nt  ret , 1 i  nkno , NumL  i  nks ; 

Int  fd[2]; 

char  *cp; 

struct  LlnkTB  *p: 

void  FT_1n1t(); 

process  any type  tp; 

process  service  Serv; 

process  froute  Router; 

process  rcvuser  Rcvuser; 

/*  External  address  and  size  of  image  of  Link  MONITOR  variables  V 
/*  It's  really  a  different  "struct  montbl  s",  but  ...  */ 

PUBLIC  struct  montbl  s  *LMON_TBL; 

PUBLIC  1nt  LM0N_SI2E; 

char  "rcvname  ■  "rcvuser  x"; 
char  "froutname  ■  "froute  x"; 
char  "servname  *  "service  x"; 
char  *monname  «  "MONITOR  x"; 
char  *fopname  ■  "fout  x"; 
char  *fipname  ■  'fin  x"; 
char  "fupname  ■  "user  n  x"; 

/*  Initialize  some  PUBLICS  used  by  Window  Manager  and  errmsg( )  */ 
G_argvO  •  argv[0];  /*  Global  access  to  program's  name  "/ 

G_flagr  ■  False; 

G_ma1np1d  »  (process  anytype)c  mypid(); 
c_setname(G_mainp1d, "Main" ) ;  ~ 

/*  Save  current  TTY  state.   All  errmsg( )  requests  and 
ASSERT  failures  assume  It's  been  saved.  */ 
save_tty(STDOUT,  G_savearea) ; 

/*  Process  Input  args,  yields  G_flag?,  NodelD,  NodelDs  and  NumLlnks  */ 
cp  ■  argv[ 1  J ; 

1f(  argc  >  1  &&  *cp  «  '-'  )  {      /*  Process  flags  */ 
wh1le(*++cp  !■  NC) 
sw1tch(*cp)  { 
#1fdef  NOWM 

case  'r':  /*  Remote  Proto  execution  -  only  without  Windows  */ 
G_flagr  •  True; 


#end1f 


break; 


default: 

fprintf (stdout, "%$:     '%C  flag  unrecognized\n" ,G_argvO, *cp) ; 
_  ,.ar9c  "  °'  /*  Ugly  trick  to  force  'Usage'  message  below*/ 

}  /*  end  switch  &  while  */ 
argc--;  argv++;  /*  Ignore  flags  1n  remaining  argv  processing*/ 

NodelD  =  *(argv[1]); 

NodelDs  ■  argv[1];  /*  save  nicknames  */ 

NumLlnks  »  argc-2; 

if  (argc  <  2  II  NumLlnks  >  MAX! inks)  { 

/*   if  argc»«2,  no  links  are  opened  */ 


Jun  25  05:11  1987   netlayer.cc  Page  13  App .  2-24 

f pr intf ( stdout, 

"%s:  Usage:   %s  [-r]  N1ds  [Ids.dev]  . . . \n\n" ,G_argvO,G  argvO); 
1f(  ! 1satty(f 11eno(stderr))  )  {  /*  If  I/O  to  file,  */ 
fprlntf (stderr , 

"%s:  Usage:   %s  [-r]  N1ds  [Ids.dev]  . . ,\n\n" ,G_argvO.G_argvO) ; 

ex  1 1 ( 4 ) ; 
} 
#1fndef  NDWM 
wcreatel ) ; 

G  ma i nwi ndow=wopen( ) ; 
#else~ 

1f(  G_flagr  «  True  )  { 

G_ma 1 nw 1 ndow  ■  f open( "Proto-stdout ■ , "w" ) ; 
1f(  G_ma1nwindow  «  NULL)  { 

fpr Intf (stderr, "%s :  can't  create  'Proto-stdout '\nM ,G  argvO); 
exit (3); 
> 
) 
el  se  { 

G_malnw1ndow«f open( "/dev/tty" , "r+") ; 

1f(  G_mainw1ndow  «  NULL  )  errmsg( "Main:  tty  open  failed" ,0); 

setbu? (G_ma1nw1ndow,NULL) ;       /  No  buffering  on  tty  */ 

#end1f 

wprlntf  ( G_ma 1 nw 1 ndow , "Main  has  begun\n"); 
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/*  Initialize  remaining  PUBLIC  Information  and 

Create  node-wide  processes  -  Rcvuser ,  Router,  Serv  */ 

FT_1nit();  /*  Initialize  ESC  character  translator  */ 

/*  Now  determine  how  many  times  packets  can  be  forwarded  */ 
G_maxfwds  -  (NumLlnks+MINfwds)  >-  MAXfwds  ?  MAXfwds  :  NumL 1 nks+MINf wds 
Rcvuser  ■  create  rcvuserO: 
rcvname[str len(rcvname)- 1 ]  ■  NodelD: 
c_set name (Rcvuser , rcvname) ; 

Router  »  create  f route(NodeID, Rcvuser , Linktable) ; 
froutname[strlen(f rout name)- 1 ]  ■  NodelD; 
c_setname( Router , f rout name) ; 
Serv  ■  create  service(NumLinks*MAXf r_l ) ; 
servname[strlen(servname)- 1 ]  ■  NodelD; 
c  set name( Serv . servname ) ; 
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/*  Open  link  devices  and  create  Link  Layer  processes  */ 

argv  +■  2;   argc  -■  2;       /*  Only  look  at  "ids, dev"  pairs  */ 
for(l 1nkno»0;  1 1nkno<MAXl Inks ;  11nkno*+)  { 

p  ■  &L1nktable[ 1 1nkno] ; 

p->1d  ■  NC; 

p->1ds  «  NULL; 

#1fndef  NOMONIT 

/*  Point  Mvars  to  a  private  copy  of  Link's  MONvars  */ 
p->Mvars  »  (struct  montbl_s  * )mal 1 oc( LMDN_SIZE ) : 
1f(p->Mvars  -■  NULL)  errmsgt "Main :  malloc  failed" , LM0N_SIZE ) ; 
memcpy(p->Mvars,LMON_TBL,LMON_SIZE); 
#end1f  NOMONIT 
} 

for(  1 1nkno»0;  1 1nkno<NumL1nks;   1 1nkno++  )  { 
p  -  &Llnktable[l inknoj: 
p->lds  ■  argv[ 1 mknoj ;  /*  save  link  Ids  */ 

/*  Find  the  ','  separating  ids  and  dev  •/ 
1f(  C  cp  «  lndex(p->ids, ' , ')  )  «  NULL) 

errmsgf "Main:  no  ','  after  ids  1n  link  arg" , 1 1nkno) ; 
1f (  *argv[1]  -*  ' , '  ) 

•rrmsg( "Main:  ','  begins  ids  in  link  arg" , 1 1nkno) ; 
*cp++  ■  NC;      /*  Effectively  ends  Ids  string,  then  points  to  dev  */ 
p->ld  ■  "p->lds;  /*  save  node  at  end  of  link  */ 

p->updown  ■  True;  /*  Assume  link  will  be  opened  V 

p->state  »  L_DISC;  /*  Initial  state*d1sconnected  */ 

p->lname  ■  cp;  /*  Entire  string  following  'Ids,'  1s  'dev'  */ 

/*  Open  Physical  Layer  (Level  1)  hardware  device,  returns  fd  ■  file  desc's  */ 
1f(  G  flagr  -=  True)    /*  Remote  mode  requires  standard  I/O  */ 

ret  •  openLevK  p->lname,  fd.  STDIN,  STDOUT,  linkno); 
else 

ret  •  openLev1(  p->lname,  fd,  G_ma 1 nw 1 ndow ,  G_ma 1 nw 1 ndow ,  linkno); 
1f  (  ret  )  errmsgt "Main:  openLevI  fa1 led" , 1 Inkno) ; 
p->rdev  •  fd[0] ; 
p->wdev  ■  fd[ 1] ; 

p->outproc  ■  tp  ■  create  f output(p->1d,p->wdev,p, Serv) ; 
/"  Name  That  Process  */ 

f opname[strlen(f opname)-1 ]  ■  p->1d; 
c_setname( tp, f opname) ; 
/*  Create  input  handler,  passing  'foutput'  1n  "tp"  */ 

tp  «  create  f 1nput(p->1d,p->rdev, 1 Inkno, tp, Router , Serv, p) ; 
f 1pname[strlen(f 1pname)-1 ]  *  p->1d: 
C  setname( tp, f Ipname) ; 
> 

/*  Create  MONITOR  and  User  processes,  if  any.  */ 
#1fndef  NOMONIT 

monnamet strlen(monname)-1 ]  »  NodelD; 

c_setname(create  M0NIT0R(Router .NodelD.G  ma  1 nw 1 ndow ) , monname ) ; 
#end1f 
#1fndef  XOuser 

tp  ■  create  user(Router .NodelD, 1 ) ;  /*  User  with  ID  1  */ 

f upnamet strlen(fupname)-3]  ■  '1'; 

f upnamefstrlen(fupname)-1 ]  «  NodelD; 

c_setname( tp, f upname) ; 
#end1f 
#ifdef  X2user 

tp  »  create  user(Router .NodelD, 2) ;  /*  User  with  ID  2  */ 

fupname[strlen(fupname)-3]  «  '2' ; 

C  set name! tp, f upname) ; 
#end1f 

1f(  G_flagr  "  False  )  { 

wprintf  (G_mainwindow, "Main  completed\n" ) ■ 

} 
> 

#undef  STDERR 
#undef  STDOUT 
#undef  STDIN 
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/ 


*  Accepts  forwardmsg  request  from  'f Input',  or  fsendmsg/f control  requests 
from  a  user.   Packets  are  routed  to  this  node's  rcvuser  process  If 
the  destination  appears  1n  NodelDs,  otherwise  the  packet  Is  forwarded 
to  an  outgoing  Link  via  the  appropriate  'foutput'  process. 

process  body 

f  route( node  1  d, Rcvuser , L 1 nktab 1 e ) 

< 

1nt  1nl Ink, Priority; 

register  1nt  len;  /"   use  Int  (vs.  CH)  */ 

register  CH  from,  to,  net_type; 

register  Route_t  1  Ink;    - 

CH  pkt[MAXpkt]; 

Error_t  ret; 

WIN  win; 

w1n«Wopen( ) ; 
LOOP 
select  < 

accept  forwardmsgdnl  Ink, Pkt, From, To. Uen, Net  type)  { 
/*  Copy  to  local  variables  •/ 
len  ■  (Int) Len;  to  ■  To;  from  ■  From;  net_type  ■  Net  type; 
1f(  len  >  MAXpkt  ||  len  <  0)  errmsg( "f route  11", len); 
/*  Above  1s  sanity  check,  "...can't  happen. . . n  */ 
miink  ■  InUnk;  memcpy(pkt  ,Pkt  ,Len) ; 
treturn;  /*  Allow  process  to  continue  */ 

link  ■  nxt  L1nk( Inl 1nk,f rom, to); 
#1fdef  BTRACE 

If (1  Ink  <  R_L0)  <       /*  Handle  non-forward  trace  differently  */ 
TRACEtrtrace, (win. •  User  Xd  %c  In  on  %c  (to  %c  on  %c)len  %d\n", 
net_type&uIDMSK.from, ml  Ink, to. 1  Ink, len) ) ; 
)  else  { 

TRACE(rtrace, (win, ■  User  %d  %c  In  on  Xc  (to  °/.c  on  Xc)len  %d\n", 
net_type&uIDMSK,from.L1nktable[( 1nt ) Inl Ink] . 1d, to, 
Llnktable(( Int ) 1  Ink] . Id. len) ) ; 

*end1f 

1f(l1nk  <  R_L0  ||  (net_type&cntMSK)  >-  G_maxf wds'cntINC)  ( 

/*  Reached  destination  (or  error)  or  forwarded  too  many  times  */ 
Rcvuser. f rece1vemsg(pkt . f rom, to, (CH) len, net  type&uIDMSK) ; 
}  else  { 

net_type  ■  net_type  +  cntINC:        /*  Increment  forward  count  V 
Priority  -  FPrlor;  /*  Use  Forwarding  priority  */ 

ret  ■  L1nktable[( 1nt)l Ink] .outproc.fwdmsg 

(  Priority,  pkt.  from,  to.  (CH)len,  net  type  ); 
1f  (ret  !-  E_0K)  < 

/*  Errors  will  result  1n  pkt  sent  to  local  f receiver  */ 
Rcvuser. f rece1vemsg(pkt , f rom, to, (CH)len,net_type&uIDMSK) ; 
TRACEtrtrace, (win. "forwardmsg;  Error  %d  from  fwdmsg  %c\n". 
ret.L1nktable[( 1nt)l Ink]. 1d)); 

} 
or 

accept  fsendmsg(Pkt.To,Len,UID)  ( 

1f(UID  >  uIDMSK  ||  Len  <  0  ||  Len  >  MAXpkt)  treturn  u_8adArgs; 
link  -  nxt_L1nk(-1,node  1d,To);    /*  Local  ortg.,  no  mllnk  */ 
#1fdef  BTRACE 

1 f (  1 1 nk  <  R_L0  )  < 

TRACE(rtrace, (win, "  User  %a   %c  sending  to  %c  ERR  Xd:\nX.*»", 
UID.node  Id. To.  (  Int )  1  ink, ( int )Len, Pkt ) ) ; 
>  else  { 

TRACEtrtrace.  (win. "  User  %d  '/.c  sending  to  %c  link  Xc:\n%.*»", 
UID,node_1d.To,L1nktable[( Int ) 1  Ink] . 1d, 
(mt)Len.Pkt)); 

/*  Note  that  Pkt  Isn't  NC  terminated,  thus  the  "%  *s"  stuff   */ 
#end1f 
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if  (  link  »»  R_ThisNode  )  { 

Rcvuser.f rece! vemsg(Pkt , node_id. To. Len.UID) : 

treturn  U  OK; 
) 

1f  (  link  ■■  R_BadDest  )  treturn  U_NoL1nk; 
if  (  link  ■■  R  Down  )  treturn  U_Down; 
1f  (  link  >«  R~LO  )  {       /•  Send  this  packet  on  a  Link  •/ 

Priority  ""UPrlor;  /*  User  priority  */ 

ret  *  L1nktable[ ( int ) 1  Ink] .outproc. fwdmsg 

(  Priority,  Pkt,  node_1d.  To,  Len,  (CH)UID  ); 

if  (ret  !«  E_0K)  { 

TRACE(rtrace, (win, "f sendmsg:  Error  %d  from  fwdnsg  %c\n". 
ret,L1nktable[(lnt)l ink] . Id)); 

> 

treturn  ret; 
> 

el se  errmsg( "F route  12" , ( int )1 ink) ;  /*  ".. .can' t  happen. . . "  */ 
treturn  U_Down;  /*  This  line  keeps  CC  happy  */ 


) 


accept  f control (req.dest)  { 

link  •  control  L1nk(req.dest ) ;       /*  Find  a  link  */ 

1f(  link  »■  R_BadDest  )  treturn  U_NoL1nk; 

1f(  link  -■  R~Down  )  treturn  U_Down; 

1f(  link  <  R_L0  )  treturn  U_BadArgs;         /"  Catches  garbage  */ 

/*  link  is  good  —  handTe  request  */ 
ret  ■  L1nktable[ ( int ) 1  ink] .outproc. fctrl (req) ; 
treturn  ret; 
) 
> 
ENDLOOP 
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/  Makes  requests  of  the  Frame  level  via  fsendmsg  ana  fcontrol .  */ 

/    Without  a  Window  Manager,  only  one  process  can  read  the  */ 

/*    terminal:   If  there  is  a  MONITOR.  1t  reads  the  terminal;  */ 

/*    otherwise  there  1s  one  user  process  reading  the  terminal.  */ 

#1fndef  XOuser 

process  body 

user(Router.  nodelD,  userlD) 

char  1 Inebuf [1+MAXpkt+1] ;   /*  Room  for  dest  ID  +  pkt  *  '\0'  */ 

1nt  len; 
UError_t  ret ; 
WIN  win; 

w1n»Wopen( ) ; 

wprlntf  (win, "user  %d  %c  begins:\nu .userlD,  nodelD); 

LOOP 
/*  Read  from  screen  */ 

len  ■  wgetl 1ne(w1n,  llnebuf,  slzeof  llnebuf); 

ret  -  dc_user( 1 inebuf,  len,  win,  Router,  nodelD,  user ID)  ■ 

1f(  ret  -»  u  Term)  { 

wprlntf  Twin, "user  %d  %c  ends :\n" .userlD,  nodelD); 

return;         /"  Process  completes  via  return  */ 

lf(  ret  !■  u  OK  ) 

wprlntf  Twin. "Error  %a   sending  User  %d  %c  message!\n", 
(Int)ret,  userlD.  nodelD); 
ENDLOOP 
> 
#end1f 
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process  body 
rcvusert ) 
{ 

WIN  win: 

win«Wopen( ) : 

LOOP 

accept  f rece1vemsg(pkt , f rom. to. len.userlD)  { 

wprintf  (w1n,"Msg  received  for  %c   from  User  %d  %c  :\n%.*s" 
to, user ID, from, len.pkt) ; 

/*   Uses  up  packets  somehow...  */ 
} 
END LOOP 
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#1fndef  N0M0NIT 

/*  MONITOR  uses  Main's  window  as 
"operator's  console"  */ 
process  body 

MONITOR) Router,  nodelD,  win) 
< 

char  1  tnebuf  [ 1*1*MAXpkt*1 ] ;   /*  Room  for  M0N_1nd  ♦  dest  ID  *  pkt  *  '\0'  */ 

1nt  Ten; 

char  *cp; 

UError_t  ret; 

delay(3):  /*  wait  for  malnO  to  say  It's  complete  */ 

wprlntf  (win, "I  am  MONITOR  %c\n" .nodelD) ; 

LOOP 


/*  Read  from  screen  */ 

1f  (  (len  ■  wgetl 1ne(win, 1 inebuf .sizeof  llnebuf))  <■  0 
|T  *1  inebuf  ■  ■  CNTLd  )  { 
wprmtf  (win,"    MONITOR  %c   quits!  !\n"  .nodelD): 
delay  10;       /*  Walt  for  output  buffers  to  empty  */ 
return;         /*  Process  completes  via  return  "/ 

cp  ■  1 1 nebuf ; 
/*  Check  for  MONITOR  command  —  after  "If",  len  and  cp  have  Oeen   adjusted  */ 
/*  to  reflect  the  remainder  of  the  line  following  MON  Ind.   V 

If  (  "cp  «  M0N_1nd  &&  ((cp**, len--  "1)  ||  *cp  T»  MON  fnd))  ( 
1f  (  len  <-  0  )  continue;        /*  Ignore  null  commands  */ 
/*  Do  A  MONITOR'S  Job  */ 
do_mon1tor(cp,  len,  win,  nodelD); 
>  else  <  /•  tjser  mput  */ 

ret  ■  do  user(cp,  len,  win.  Router,  nodelD,  0): 
1f  (  ret  ■«  U  Term)  { 

wprlntf  (wm."  MONITOR  Xc  term1natesl\n"  .nodelD) ; 
delay  10;    /*  Walt  for  output  buffers  to  empty  "/ 
return;  /*  Process  completes  via  return  V 

1f(  ret  I-  u  OK  ) 

wprlntf  Twin. "Error  Xd  in  MONITOR  %c  message!\n" , ( int )ret .nodelD) ; 

ENDLOOP 
> 
fend if 
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/*  See  README  file  for  Info  on  "Proto"  */ 

# Include  <ctype.h> 

#include  <stdlo.h> 

I Include  <errno.h> 

/Mfdef  BSD 

#1nclude  <sys/file.h> 

#end1f 

#1fndef  NOWM 

0 include  <ccwra.h> 

#endlf 

# include  "proto.h" 

^include  "monvars .  h" 


/*  LINK  LAYER  —  Header.  Functions  */ 

/*   Header  Information    */ 

/*  INFO  frame  "seq"  field  values  are  determined  from  the  defines 
below.   F_INF_0  1s  the  offset  added  to  the  'true'  sequence 
number.   F_INF_MAX  is  the  maximum  value  of  "seq"  that  1s  treated 
as  an  INFO  frame.   (1nt)F_INF_0  should  be  less  than  (1nt)F  INF_MAX. 
All  (1nt)F_xxx  values  from  'FrameTypes'  (below)  should  be  outside 
the  range  F_INF_0  to  F  INF  MAX.   */ 
#define  F_INF_0   '0'     /*  Use  ASCII  '0'  as  lowest  xmitted  "seq"  number  */ 
#define  F_INF_MAX  ( (CH)F_INF_0+MAXseq)   /*  Highest  xmitted  "seq"  number  V 

enum  FrameTypes  {       /*  Arbitrary  values  assigned  (but  mneumonlc)  */ 

/*  These  values  are  the  actual  transmitted  (CH)  in  the  "seq"  field, 
and  thus  must  differ  from  the  values  of  "seq"  that  identify  real 
INFO  frames.   (See  "F_INF_0"  above.)  */ 

/*  Should  be  "F_xxx  ■  (CH)  'A'",  but  CCC  won't  al lowl  */ 
/*  For  portability,  most  F  xxx  references  should  be  */ 
/"  of  the  form  "(CH)  F_xxx~.  */ 


F 

ACK       ■ 

'A' 

f' 

"NACK    - 

'N' 

F 

HEAR    - 

'H' 

f 

START    ' 

'S 

F" 

"STACK    - 

'T 

f" 

"DISC    " 

•0' 

f' 

AMD ISC 

'   • 

#deftne  NUMcntl 


/*  Number  of  Control  Frames  types  (non-INFO)  */ 


enum  Status  <  NoFrame»0  /*  Assumed  zero  */ 

/*  Several  codes  -  did  in  - 

.FrSHORT  /*  did  in  ->  f  input 

.FrCOUNT  /*  dlciin  ->  finput 

.FrCKSUM  /•  did  in  ->  finput 

.FrBIG  /*  alciln  ->  finput 

.FrBADCn  /*  dlciin  ->  finput 
>; 


finput  ->  foutput  */ 

Frame  too  small  */ 

Frame. 1  en  !■  characters  read  V 

Checksum  failed  */ 

Too  many  chars  in  incoming  Frame  V 

Invalid  chars  in  incoming  Frame  */ 


typedef  enum  Status  Status_t; 

r    Frame  Buffer  related  information  (FBuf  defined  earlier)  */ 

#define  FHDRsize  6  /*  Xmitted  stuff  in  header  Besides  packet.  Should  be-  •/ 

/"  #define  FHDRsize  OFFSET(Fbuf .packet [0] )  -  0FFSET( Fbuf , seq)  but  CCC  barfs  */ 
#define  MAXfrsize  (slzeof (Fbuf )-slzeof (bi ts) )   /*  Exclude  control  bits  */ 
#define  MINfr    3       /*  Minimum  valid  length  Frame.  */ 
#define  Lctl    3       /*  Length  of  most  Control  frames  */ 
*deflne  Lctl_STK  4      /*  Length  of  STACK  frames  */ 
»define  FNULL  ((Fbuf  *)0) 

/"  Minimum  frame  address  is  CH  MAX-M  to  allow  any  (CH)  to  be  */ 

/*   distinguished  from  a  real  ?Fbuf  *)   */ 
#define  FMIN  ((Fbuf  " ) (CH_MAX*I ) ) 

/*  values  of  bits  in  (Fbuf)x.con  */ 
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#define  conlDLE  1«7    /*  Idle  Frame  -  only  touched  by  "service"  */ 

/*  Frame  Queue  Element  structure  V 

/*  The  FrameOE  structure  Implements  a  doubly-linked  circular  queue  as 

an  array  of  "FrameOE"  elements.   The  "Head"  of  the  queue  Is  one  element 
of  the  array  (not  typically  element  0)  and  an  empty  queue  has  the 
"prev"  and  "next"  Items  of  the  "Head"  element  both  set  to  the  index 
of  the  "Head"  element.   The  "tics"  Item  1s  used  only  In  the  "SendO" 
frame  timer  queue  In  ' f output ' ,  but  doesn't  waste  enough  space  to 
justify  another  structure  for  the  other  queues.   Queue  elements  are 
manipulated  by  2  functions:  Insert()  and  Remove( ) .   Insert()  will 
automatically  Remove ( )  an  element  from  an  existing  11st  (If  any) 
before  inserting  it  as  a  new  element  m  "front  of"  another  designated 
element.   Insert()1ng  1n  "front  of"  the  queue  "Head"  places  the  new 
element  at  the  end  of  the  queue. 

struct  FrameOE  {  /*  Frame  Queue  Element  */ 

short  next;  /*  forward  link    */ 

short  prev;  /*  backward  link    */ 

short  tics;  /*  count  of  timer  "tics"  until  Timeout  */ 

Fbuf  'item;  /*  (usually)  a  FrameBuf  pointer  */ 

typedef  struct  FrameOE  fOe  t; 

/fdefine  Qnull  -1        /*~Null  pointer  value  for  FrameOE  arrays  */ 

/*  (This  requires  that  next/prev  be  signed.)  V 

/*  Foutput  related  data  */ 
/*  Initial  Timeout  Values  (m  "tics"  where  1  tic  ■  ftlmer 

calling  f output . ft ime( ) 
(These  should  be  2  to  5  times  the  expected  time  for  a  response... 
The  time  between  "tics"  1s  determined  by  ftlmerGap  below.) 

#def1ne  ftlmerGap  15  /*  seconds  between  calls  to  foutput .ft 1me( )  */ 

#def1ne  T0_ACK  1        /*  Interval  of  no  reverse  traffic  before  forcing  ACK  */ 

#def1ne  T0_Frame  3      /*  Ties  before  assuming  INFO  frame  was  lost  */ 

/*  (To  avoid  extra  Time-outs,  this  should  be  >«  (T0_ACK)+2  since  T0_Frame 
times  from  transmission  and  T0_ACK  times  from  reception.)   */ 
#def1ne  T0_START  1       /*  Ties  before  assuming  START  was  lost  "/ 
#def1ne  T0_DISC  1       /•  Tics  before  assuming  DISC  was  lost  */ 

/*  This  defines  the  expected  interval  between  HEARtbeat  frames  and  the  number 
of  missing  pulses  that  result  1n  the  "Missing  HEARtbeat"  complaint. 
"TOJHEAR"  1s  the  number  of  "tics"  (ftlmerGaps)  between  transmitted 
HEARtbeat  frames  on  an  otherwise  idle  outgoing  link.   "PulseGap"  is  the 
number  of  seconds  of  missing  Input  used  by  'flnput'  to  declare  a  "pulse" 
failure.   "PulseGone"  consecutive  "pulse"  failures  without  intervening 
Incoming  traffic  results  1n  the  "Missing  HEARtbeat"  output  message. 
*/  /*  (PULSE  nominally  120  seconds)  */ 

#def1ne  TOJHEAR  ( ( 1nt)( 120/f tlmerGap) )   /*  sec.  between  sending  HEAR  frames  "/ 
#def1ne  PulseGap  (( Int )(T0_HEAR*f tlmerGap) )  /*  Max.  seconds  between  frames  */ 
ifdeflne  PulseGone  4  /*  g    missing  pulses  before  complaint  */ 

#def1ne  MAXSattempts  10  /*  0    tries  to  get  START  accepted  */ 
#define  MAXDattempts  15  /*  0    tries  to  get  DISC  accepted  */ 
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/*  PROCESS  SPECIFICATIONS  —  Private  to  Link  Layer  */ 
process  spec 
o"lco1n(process  foutput  foutp.lnt  outdevice, struct  LlnkTB  *Lp); 

process  spec 

dlc11n(1nt  Indevlce, process  service  Serv, struct  LlnkTB  *Lp) 

trans  Fbuf  *f ramercvf ) ; 
}; 

process  spec 
f t1mer(process  foutput  Foutput);         /*  Cheap  Timer  for  'foutput'  */ 
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/•  MONITOR  variables  for  the  Link  Layer  */ 
#1fndef  NOMONIT 

#undef  MONPTR    /*  define  access  to  MONITOR  "trace"  variables  */ 
*def1ne  MONPTR  Lp->Mvars->      /*  "Lp"  Used  by  all  Link  Layer  */ 

#def1ne  F(var)  struct  flag  var; 

#def1ne  C(var)  struct  count  var; 

#def1ne  P(var)  struct  picture  var; 

struct  montbl_s  {  /*  MONITOR  variables  */ 

#1fdef  BTRACE    /*  Only  define  If  TRACE  macro  expands!  */ 

F(otrace)  /*  TRACE  on  for  output  char,  processing  */ 

F( (trace)  /•  TRACE  on  for  Input-related  things  *7 

F(ctrace)  /*  TRACE  on  for  all  Input  Characters  */ 

F(frtntr)  /*  TRACE  on  for  "framemO"  processing  */ 

F(reqtr)  /*  TRACE  on  for  "framereqO"  processing  */ 

F(sendtr)  /*  TRACE  on  for  all  SendC/Sendl  actions  */ 

F(totrace)  /*  TRACE  1n  all  Timeout  processing  */ 

yfendlf 

C(badfrs)  /*  Count  of  Bad  Frames  received  */ 

C(dl1n)  /*  Count  of  frames  received  (all  returns  to  dlc11n)  */ 

C(dlout)  /*  Count  of  frames  sent  (attempts)  */ 

P(nextlnseq)        /*  Last  value  of  Lp->ExpectedF  •/ 

P(nextoutseq)       /*  Last  value  of  Lp->NextF  */ 

char  *_p; 
#undef  F 
#undef  C 
#undef  P 

#def1ne  F(var)  <"var",0>.       /"  Flag  Initially  reset  */ 
#def1ne  Fset(var)  {"v»r",1).    /*  Flag  Initially  set  •/ 
♦define  C(var)  <"var",0>, 
♦define  P(var)  ("var".0>, 
>  montbl  ■  < 
#1fdef  BTRACE    /*  Only  define  1f  TRACE  macro  expands!  */ 

F(otrace) 

Fsetdtrace) 

F(Ctrace) 

Fsettf rlntr) 

Fset(reqtr) 

Fset(sendtr ) 

Fset( totrace) 
#end1f 

C(badfrs) 

C(dl In) 

C(dlout) 

P(nextlnseq) 

P(nextoutseq) 

(char  *)0 
}; 

*undef  F 
#undef  C 
#undef  P 

/*  Slobals  used  by  ma1n()  to  Initialize  "Mvars"  In  LlnkTB  struct  */ 
struct  montbl  s  *LM0N  TBL  ■  &montbl : 
int  LMON  SIZE--  slzeof (struct  montbl  s); 
#end1f  NOMONIT  ~ 
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/*    FUNCTIONS  used  by  Link  Layer   */ 

PUBLIC  1nt  G_ma 1 nw 1 ndow ;         /*  Default  window  for  error  output  In  maln()  •/ 

/*  Frame  Queue  manipulation  functions  */ 

/*  Remove  —  Remove  an  fOe  from  a  queue  */ 

PRIVATE  short  /*  Returns  value  of  'element'  */ 

Remove(fO,  element,  max  element) 

fOe_t  fOH;      /*  the  queue  array  */ 

short  element;   /*  element  to  remove  from  queue  */ 

short  max_element;       /"  highest  valid  element  In  queue  */ 

/*  (must  Include  "Head"  ) 

/*  'element'  must  be  LESS  THAN  this  value.  */ 


register  fOe  t  *ep; 

7*  Check  'element'  bounds  */ 
ASSERT(element  >■  0  &&   element  <  max_element) ; 

ep  »  &fQ[element] ; 

/*  Assure  'element'  Is  In  a  queue  &    doesn't  point  to  self  or  "wild"  */ 
ASSERT(ep->next  [■  Onull  &&  ep->next  (•  element  &&  ep->next  <=  max  element); 
ASSERT(ep->prev  !-  Onull  &&  ep->prev  !■  element  &&  ep->prev  <=  max~e1ement) ; 

/*  Validate  old  links  before  destroying  */ 
ASSERT{fO[ep->prev] .next  ■■  element); 
ASSERT(fQ[ep->next] . prev  «-  element); 

fO[ep->prev] .next  ■  ep->next; 

f G[ep->next] .prev  *  ep->prev; 

ep->prev  ■  ep->next  ■  Onull;         /*  Null  Into  links  ■>  'not  in  queue'  */ 

return(  element  );  /*  Allows  Remove ( )  in  expressions  */ 


/*  Insert  —  Insert  an  fOe  (frame  queue  element)  1n  front  of  another 
fOe  already  on  the  selected  queue.  */ 

PRIVATE  short  /*  Returns  value  of  'new_element'  parameter  */ 

Insert(fQ,  new_element,  current  element,  max  current) 

fOe_t  f0[];  /*  The  queue  array  "7 

short  new_element;       /*  element  to  Insert  */ 

short  current_element ;   /*  element  to  Insert  In  front  of  */ 

short  max_current;       /*  max.  valid  value  of  current  for  this  queue,  */ 
/"  typically  the  "Head"  element. 
/•  new_element  must  be  LESS  THAN  this  value!  */ 
/*  (allows  error  checks  to  be  performed)  */ 

register  fOe_t  *nep,*cep; 

/*  Check  bounds  of  elements  */ 
ASSERT(current_element  <■  max_current  &&  new  element  <  max  current); 
ASSERT(current_element  >•  0  &&  new_element  >■  0) ; 

/*  Check  that  current_element  Ts  in  a  queue  and  that  we're 

not  attempting  to  Insert  current_element  in  front  of  Itself  */ 
ASSERT(current_element  !-  new_element ) ; 
ASSERT(fO[current_element] .prev  1»  Onull); 
ASSERT(fO[current_element ] .next  !«  Onull); 

/*  If  new  element  already  1n  a  queue.  Remove ( )  1t.  */ 
1f(  (nep  »  &fQ[new_element] )->next  I-  Onull) 

(void)Remove(fO,  new_element ,max_current ) ; 

/*  nep  points  to  element  to  insert  */ 
cep  ■  &f Q[current_element ] ;  /*  cep  points  to  current  element  */ 
nep->next  ■  current_element ;         /"  Link  In  front  of  current  element  */ 
nep->prev  ■  cep->prev; 

fO[cep->prev] .next  -  new_element;    /*  Point  old  prev.  to  new  */ 
cep->prev  =  new  element;  /*  and  current  to  new  */ 

returnf  new_element  );  /*  Allows  Insert()  in  expressions  */ 
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/*  LINK  Layer  PROTOCOL  FUNCTIONS  */ 

/*  Data  Link  ESC  processing   */ 

#def 1 ne  escO( ch )  ( E scape_tab 1 e [ ( CH ) ( ch )&CH_MASK ] | -NC ) 
#define  esc(ch)   Escape_table[ (CH)(ch)&CH  MASK] 
#define  unesc(ch)  UnEscape_table[ (CH)(ch)&CH  MASK] 

#def1ne  ESC_entry(or 1g. repl )  Escape_table[ (CH) (orig)&CH_MASK]  -  repl;\ 
UnEscape_table[(CH)(repl )&CH_MASK]  «  orig 

PRIVATE  CH  Escape_tab1e[CH_MASK+1];      /*  CH  SIZE-b1t  chars  */ 
/•  Y1e1ds~NC  ('\0'~"or  char  to  follow  escape  on  output  */ 
/*  ***  '\0'  cannot  be  a  replacement  char  ***     */ 
/*  The  defined  ESC,  SOH,  and  EOB  characters  must  be  in  this  table  */ 

PRIVATE  CH  UnEscape_table[CH_MASK+1];    /*  CH_SIZE-b1t  chars  */ 

/*  Yields  replacement  for  char  following  ESC_char  1n  input.  */ 

/•  The  un-ESC  character  must  be  1n  this  table  (It's  usually  »  ESC)  */ 

/*  The  SOH/EOB  characters  must  not  be  In  this  table  */ 

/*  since  they  cannot  validly  follow  an  ESC.  */ 


/*  Initializes  the  Escape  character  tables  at  run-t1me  */ 


void 

FT  1nit() 

{  ~ 

register  CH  *a  ■  Escape_tab1e; 

register  CH  *b  ■  UnEscape_table; 

register  mt  1 ; 

for(  1  ■  stzeof  Escape  table;  1—  >  0;  )  { 

*a++  «  NC;     Tb++  -  NC; 
> 
/*  Characters  to  be  Escaped  are  all  In  the  ESC_entry  lines  below. 

DO  NOT  change  "orig"  of  first  3  lines  —  to  change  the  ESC  character 
or  SOH/EOB,  see  the  #define  statements  earlier.   The  "replace" 
characters  for  ESC/SOH/EOB  need  only  be  changed  below. 
ESC_entry  does  not  complain  about  fools  that  map  more  than  one 
"ong"  character  to  the  same  "replace"  character. 

Parms  to  ESC_entry(orig, replace)  are: 
orig  -  character  to  be  Escaped, 
replace  ■  replacement  character  to  be  used 


ESC_entry(  ESC  char, ESC  char 
ESC~entry(  S0H~char . 'a'T 
ESC_entry(  E0B~char, 
ESC_entry(  'Q'~ 
following  handle  most  of 


);  /*  ESC  ESC's  Itself. 


*/ 


ESC   entry( 

'\b- 

,  'C  ) 

/* 

Back-space   V 

ESC   entry( 

'W 

.  'd' ) 

/* 

Back-slash  */ 

ESC_entry( 

-\f 

.  'e' ) 

/* 

TAB 

V 

ESC   entry( 

'V 

.  'f  ) 

/* 

CarrRtn 

V 

ESC  entryi 

'\n' 

.  '0') 

/* 

NewLlne 

V 

ESC   entryC 

'•' 

.  'h' ) 

/* 

AT   sign 

V 

ESC    entryt 

-\ooo- 

.'!') 

/* 

nul-~G 

*/ 

ESC   entryt 

-\003' 

.'J') 

/* 

etx-"C 

•/ 

ESC_entry( 

'\004' 

,  'k' ) 

/* 

eot-^D 

"/ 

ESC*~entry( 

-\020' 

.  '1  ' ) 

/• 

dle-~P 

V 

ESC   entry( 

' \02 1 ' 

.  'm'  ) 

/" 

dd-~o 

V 

ESC   entry! 

' \023 ' 

.  'n'  > 

/* 

dc3-~S 

V 

ESC   entry( 

'\033' 

.  'o' ) 

/* 

esc-"[ 

■/ 

ESC  entry( 

•MT7' 

.  'P') 

/* 

del 

•/ 

/*  A  test  ESC  mapping  */ 
the  UNIX(tm)  tty  chars  that  cause  problems  */ 
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/*  CRC  processing   */ 
/*  Uses  CCITT  standard  CRC  Generator:   X**16  +  X**12  +  X**5  +  1 

Routine  is  adapted  from  Kermlt  CCITT  file  transfer  programs. 

Basically  generates  CRC  4  bits  at  a  time  using  table  look-up. 

For  more  details,  see  IEEE  Micro,  June  1983.  p.  40-50  and  Refs. 
V 

PRIVATE  unsigned  short  cc1tt[]  -  { 

0x0000,  0x1081,  0x2102.  0x3183.  0x4204,  0x5285,  0x6306,  0x7387, 
0x8408,  0x9483.  0xA50A ,  0XB58B,  0xC60C ,  0xD68D .  0xE70E ,  0xF78F 

}; 

PRIVATE  unsigned  short 

crc(buffer,  nbytes  )  register  CH  'buffer;  register  int  nbytes; 

{ 

register  unsigned  short  q.  tcrc; 

register  CH  c; 

tcrc  »  OxFFFF;  /*  CCITT  using  all-ones  initial  chksum  */ 

do 

{ 

c  ■  *buffer++; 

q  ■  (tcrc  "  c)  &  OxOf ; 

tcrc  ■  (tcrc  »  4)  A  ccitt[q]; 

q  ■  (tcrc  "  (c  »    4))  &  OxOf; 

tcrc  ■  (tcrc  »  4)  *  cdtttqj; 
) 

while( — nbytes  >  0); 

retum('-tcpc)  ;      /*  CCITT  transmits  Inverse  of  computation  */ 
) 

/*  TTY-related  Functions  */ 
void 

flush  tty(fd)  1nt  fd; 
{ 
#1fdef  BSD 

int  temp; 

temp  »  FWRITE;   /*  Flush  only  output  queue  */ 

ioctKfd,  TIOCFLUSH.  ftterap); 
#else 

1octl(fd,  TCFLSH,  1);  /*  Flush  only  output  queue  */ 
#endlf 
} 
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/*  PROTOCOL  FUNCTIONS  "/ 

/•  Framing  and  Transparency  (output)  protocol  */ 

/*  Stops  if  Lp->G_restart  1s  True  before  writing.   */ 

PRIVATE  void 

FTo_pro to ( fr, outdev. Lp)  Fbuf  *  frj  int  outdev;  struct  LinkTB  *Lp; 

register  int  frcount; 

register  char  *q; 

register  CH  *p,  ch; 

/*  "obuf"  has  room  for  entire  transmitted  data  block,  */ 
/*  that  1s,  SOH/EOB  *  everything  in  between  ESCed.  */ 

char  obuf [2+(MAXpkt+FHDRs1ze+2)*2] ; 

unsigned  short  CKsum; 

frcount  ■  fr->1en;  /*  Chars  1n  Frame  */ 

p  ■  &fr->seq; 

CKsum  ■  crc(p.f rcount ) ;  /*  Cksum  on  unESCed  Frame  */ 

q  ■  obuf ; 

*q++  ■  (CH)SOH_char; 

if  (   Lp->G_restart  )  return;    /*  Stop  if  restart  requested  */ 

while  (  frcount —  >  0  )  {       /*  Copy  Frame  while  ESCing  */ 

Ch  ■  *p++; 

if  (escO(ch))  {  /*  Char,  to  ESCape  ?  */ 

TRACE (ot race, (Lp->o, "%c  c%ox%o#«%d\n" , 

Lp->1d, (CH)ch. (CH)esc(ch). frcount)); 
*q++  «(CH)ESC  char;  ch  "  esc(ch);  /*  Stuff  ESC,  replace  'ch'  */ 

} 

*q++  ■  Ch; 
> 

ch  -  (CKsum  »  CH  SIZE)  &  CH  MASK;       /'   Copy  Ckaum  while  ESCing  */ 
TRACE (otrace,(Lp->o, "%c  CK"%o:%o" . Lp->1d, ch.esc(ch) ) ) • 
if  (escQ(ch))  {*q++  »  (CH)ESC_char ;  ch  ■  esc(ch);} 
*q++  -  ch; 

Ch  -  CKsum  &  CH  MASK: 

TRACE(otrace.(Lp->o."-%o:%o\n",ch,esc(ch))); 
If  (escO(ch))  {*q++  »  (CH)ESC  char;  ch  «  esc(ch);} 
*q++  ■  ch; 

*q*+  -  (CH)EOB_char; 
1f  (  Lp->G_restart  ■■  False  )  /"  if  restart  True,  no  frame  sent  */ 

wnte(  outdev, obuf  .q-obuf ) ; 
return; 
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/*  Framing  and  Transparency  (Input)  and  Error  Detection 
protocol  function.   Code  written  directly  from  tne 
Transition  Diagrams  1n  tne  Paper.   May  not  be  efficient. 
Transition  names  appear  as  comments  to  the  left  of  the  code. 
Hreturn"1ng  from  this  function  implies  going  to  READY  state. 

*/ 
#def1ne  readCHt )  ( read( tndev.x, 1 ) ,x[0] ) 

enum  FTIState  {stREAOV , StREAD, stESCAPE) ;  /*  States  in  Diagram  "/ 

PRIVATE  Status  t 

FT1_ED_proto(fr, Indev.Lp)  Fbuf  *fr;  1nt  1ndev:  struct  LlnkTB  "Lp: 

register  1nt  count  ■  -1; 

register  CH  eh; 

register  char  "buf;  /*  addr .  to  start  storing  Incoming  Frame  V 

CH  X[l);  /"  Used  by  "readCH"  "/ 

register  unsigned  short  CKsum; 

register  unsigned  short  cCKsum;     /*  Computed  checksum  V 

enum  FT  i  State  st; 

/*  The  only  use  (so  far)  of  Lp  1s  1n  TRACE  statements.  V 

/*  CC  says  "not  referenced"  if  TRACE  1s  turned  off.  so  here's  a  reference  */ 
Lp  ■  Lp;    /*  (should  not  generate  code)  */ 

but  ■  (char  *)&fr->seq; 

st  "  stREADY;  /*  Initial  State  */ 

for(;:)  { 

ch  -  readCH( ) ; 

TRACE(Ctrace,(Lp->1  ,"/.c  ch-Ko,  st-Xd.  count  «  %d\n". 
Lp->1d,ch,st .count)); 

/*  SOH  */       If  (ch  -«  (CH)SQH_char) 

/*  -common  V       (count  «  0;  st  ■  StREAD;  continue;) 

switch  (st)  ( 
/*  non-SOH  */   case  StREADY:  continue;  /*  READY  state  */ 

case  stREAD:  /*  READ  state  */ 

Switch  (<1nt)(ch&CH_MASK))  { 
/•  EOB  "/         case  ( int ) (£OB_char&CH_MASK) :      /*  Frame  to  Error  Det .  */ 
/■  Error  Detection  protocol  starts  here  */ 

If  ((count  "  count-2)  <  MINfr  )  return  FrSHORT; 
If  (  fr->len  !■  count  )  return  FrCOUNT: 

/*  Get  cksum  */ 
CKsum  «  (CH)buf [count]  <<  CH  SIZE 

|  (CH)bUf [count-H  ]  &  CH_MASK; 
cCKsum  «  (unsigned  short )crc(buf .count ) ; 
if  (  cCKsum  l«  CKsum)  { 
TRACE ( 1  trace . ( Lp-> 1 . 

•%c   %cFTi_ED_proto:  CKSUM  over  data  was  %o-%o\n". 
Lp->1d.(cCKsum»CH_SI2E)&CH_MASK.  cCKsum&CH  MASK)  ); 
return  FrCKSUM; 
> 

/  Good  data  —  return  to  caller  */ 
return  (Status_t )f r ; 
/*  Error  Detection  protocol  ends  */ 

/*  EC  */  case  ( 1nt )( ESC_char&CH  MASK):  /*  ESC  -  ->  ESCAPE  state  */ 

{st  -  StESCAPE;  continue;  > 

} 

If  (  esco(ch)  ) 
/*  bad  ET1  */  return  FrBADCh; 

/•  C  *7        If  (  count  <  MAXfrsIze  )  buf [count**]  •  ch; 
/*  Overflo  */   else  return  FrBIG; 

continue;  /*  Get  next  ch  */ 

case  StESCAPE:  /*  ESCAPE  state  */ 

1f  (  count  >»  MAXfrsIze  ) 
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/*  bad_ET  */  return  FrBIG: 

ch  '   unesc(cn);         /*  Get  orlg.  ESCed  cnaracter.  */ 

If  (  lescO(ch)  )  return  FrBADCh; 
/*  ET  "/        buf  [count++]  -  ch; 

st  -  stREAD; 

continue; 
) 
} 
) 
#undef  readCH 
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App. 


/*  Requests  frames  via  framereq, 
/*  then  writes  them  to  outdevlce 


V 
V 


process  body 

d 1 co 1 n ( f ou tp , ou tdev 1 ce , Lp ) 


Fbuf  *fr; 


LOOP 

fr  ■  foutp. f ramereq( ) ;   /*  Request  frame  to  send  */ 

1f  (Lp->G_restart)  { 

f lush~tty(outdev1ce) ;    /*  Flush  output  buffers  if  tty.  */ 

Lp->G~restart  »  False;   /*  Reset  G  restart  */ 
> 
FTo_proto(fr, outdevlce, Lp) ;  /*  Frame  and  Transparency  Protocol  */ 

/*  (Sends  frames  to  Physical  Layer)  */ 
If  (Lp->G_restart)  { 

f lush~tty(outdevice) ;    /*  Flush  output  buffers  if  tty.  */ 

Lp->G  restart  ■  False;   /*  Reset  G  restart  */ 
> 

COUNT (dl out) ; 
EN0L00P 
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/*  Reads  Indevlce,  accepts  framercv  requests        V 
/"  from  flnput  process  */ 

process  body 

dlci 1n( Indevlce, Serv, Lp) 

( 

Fbuf  *fr  »  Serv.getFO;  /*  Get  a  frame  */ 

Fbuf  *ret; 

char  buffer[2*(MAXpkt*FHDRs1ze*2)'2*1];  /*  Room  for  ESCed  frame  *1  */ 

LOOP 

ret  -  (Fbuf  *)FT1  ED_proto(fr, Indevlce, Lp) ; 

COUNKdl  In); 

If  (  ret  >-  FMIN  ) 

TRACE(1trace.(Lp->1 . "%c   dlclin:  Seq  %c,ack  %c\n" , 
Lp->1d, ret->seq, ret->ack) ) ; 
else  TRACE(  1trace.(Lp->1 ,  "%c  dlclm:  ED  err  -  y.d\n"  ,Lp->1d,  ret ) ) ; 
accept  framercv  (  )  {         /*  Walt  for  flnput  to  ask  for  It  */ 

treturn  (ret);       /*  "ret"  could  be  a  code  or  Frame  pointer  */ 
> 
If  (ret  >«  FMIN) 

fr  =  Serv.getFO;        /*  Gave  frame  away  ,  get  new  one  */ 
ENDLOOP 
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/*  FOUTPUT  Process  —  Handles  Frame  protocol  via  accepts.  */ 

/*  Define  access  to  elements  of  Send  and  Timer  queues.   (See  below.) 
No  Freelist  1s  needed  since  only  frame  sequence  numbers  within  the  "window- 
are  active,  others  are  Implicitly  Idle.   (Controlled  by  "NextF"  and 
"ExpectedA"  variables.)   Control  Frames  are  accessed  by  their  Internal 
ID  of  the  form  "F1ACK",  "F1NACK",  etc.   Any  element  with  a  "next"  Item 
set  to  "Qnull"  1s  not  on  a  queue  (I.e.,  It's  "unqueued"). 

process  body 

foutput( 1  Ink  node,outdev,L1nkP,Serv) 

( 

/*  PRIVATE  Definitions  for  'foutput'  only   */ 

#def1ne  ToSeq(seqn)  ( (CH)( (CH)(seqn)+(CH)F_INF  0))  /*  Binary  to  External  Map  */ 
#def1ne  Modlnc(n)   ( (Seq_t)(n«MAXseq?0: n+1 ) )    /*  Increment  M0D(MAXseq+1 )  */ 
#def1ne  ModDec(n)   ( (Seq_t)(n«0?MAXseq: n- 1 ) )    /*  Decrement       "         */ 
#def1ne  BETWEEN(x.y.z)  \ 

(  (x)<-(y)&&(y)<(z)  ||  (z)<<x)&ft(x)<»(y)  ||  <y)<(z)&&(z)<(x)  ) 

/•  Send,  Timer  and  Request  Queue  defines  */ 

/*  Allocate  the  1  (or  2)  arrays  acting  as  circular ly-i inked  queues. 
Head  of  each  queue  1s  an  element  "above"  the  "regular"  elements  of  the  queue. 
Several  "macros"  are  defined  for  accessing  each  queue.   Note  that  several 
"head"s  may  exist  for  any  array,  forming  multiple  queues  within  the  array.  */ 
/*  Request  Queue  Allocation  */ 
#if  Nbuf_req  >  0        /*  Allocate  Request  queue  If  requested  */ 
fQe_t  ReqO[Nbuf_req+2];  /*  Space  for  Nbuf_req  elements  +  freelist  head 

♦  request  queue  head  */ 
#define  ReqHead  Nbuf_req        /*  This  index  Into  ReqO  Is  Req.  queue  Head  */ 
ifdeflne  ReqFree  (Nbuf_req+1)     /*  Freelist  Head  (also  max.  element  in  ReqO)  V 
/*  Empty  Request  queue  has  Head  pointing  to  itself  — 
Full  queue  indicated  by  empty  Freelist  (Free  Head  points  to  itself)  */ 
#def1ne  ReqEmptyt )  (ReqO [ReqHead] . next—ReqHead) 
#def1ne  ReqFulM)   (ReqQ[ReqFree] .  next«ReqFree) 

/*  Freelist  and  Request  queues  are  circularly  linked. 

(  ReqO[ReqFree] .next  ->  next  ■>  next  ■>  eventually  leads  to  ReqFree.) 

"ReqAdd"  selects  next  element  from  Freelist,  inserts  at  end  of  Request 
queue  and  returns  Index  of  "added"  element.   Note  that  "Insert"  also 
removes  the  element  from  Freelist,  requiring  that  ReqFree  be  the 
"maxcurrent"  element  1n  the  call  to  "Insert". 

"ReqGet"  selects  next  element  from  head  of  Request  queue,  adds  to  end 
(arbitrary)  of  Freelist  and  returns  index  of  selected  element. 
■Insert"  also  removes  element  from  Request  queue.   "ReqHead"  is  used 
as  "max_current"  parameter  since  element  should  not  be  on  Freelist. 

#def  i  ne  ReqAdd( )  ( I nser t ( ReqO , ReqO [ ReqF ree ] . next . ReqHead , ReqF ree ) ) 
#def 1 ne  ReqGet ( )  (I nsert ( ReqO , ReqO E ReqHead ] . next , ReqFree . ReqHead ) ) 
#endif  Nbuf_req  >  0 

/*  Send  and  Timer  Queue  Allocation  */ 

/*  S_T_Q  (Send  and  Timer  Queues)  consists  of  an  array  acting  as  2  circularly- 
linked  queues.   The  two  "head"s  form  the  Send  queue  and  the  Timer  queue. 
No  count  1s  kept  of  the  number  of  elements  on  either  the  SendQ  or  TlmerO. 
This  allows  S_T_0  elements  to  be  "deleted"  without  knowing  the  particular 
Oueue  on  which  they  appear.   If  it  is  necessary  to  "know"  which  Queue  an 
element  Is  on  (1n  future  enhancements),  an  associated  array  (S  T  Qsupp? ) 
could  be  used.   For  example,  S  T  Qsuppfelement] . timq  could  be  a  BOOL 
that  is  True  only  if  S_T_Q[element ]  is  on  the  TlmerO. 

fQe_t  S_T_Q[  NUMseq      /*  Room  for  every  sequence  number  */ 

♦NUMcntl       /*  plus  one  of  every  control  frame  type  */ 
+1+13;        /*  plus  Heads  for  Send  and  Timer  queues  */ 
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enum  IFrameTypes  {  F1INFO-0     /*  Used  to  cover  all  "cases"  of  frame  types  V 

,F1ACK>NUMseq 

.F1NACK 

.F1HEAR 

.F1START 

,F1 STACK 

.F1DISC 

.F1AM0ISC 

, SendHead  /"  Last  2  elements  are  queue  "heads"  and  */ 

, Timer-Head  /*   MUST  be  1n  this  order.  •/ 

>; 

/*  Empty  queues  have  "heads"  pointing  to  themselves.  */ 
#def ine  SendEmptyO      (S_T_0[ SendHead] . next ■ -SendHead) 
yfdef  ine  T1merEmpty( )     (S_T_Q[ TimerHead J .  next"TimerHead) 

/*  Queued/unqueued  eTement  tests  (only  for  S_T_Q  elements)  */ 
#def1ne  Oued(element )  (S  T_Q[element ] . next  !*  Qnul 1 ) 
^define  unQued( element )  Ts~T_Q[element] .next  ■•  Qnull) 

/*  "SendAdd"  Inserts  the  specified  element  at  the  end  of  the  Send  queue. 

(TimerHead  1s  used  as  "maxcurrent"  parameter  so  automatic  Remove  from 

any  queue  will  work.) 
V 
#def ine  SendAdd( element )         ( Insert(S_T_0. element, SendHead, TimerHead) ) 

/*  "SendGet"  removes  the  first  element  from  the  Send  queues  and  returns 

the  Index  of  the  removed  element. 
V 
#def 1 ne  SendGet ( )        ( Remove( S_T_Q . S_T_Q [ SendHead ] . nex t . SendHead ) ) 

/*  "TlmerAdd"  Inserts  "element"  at  the  end  of  Timer  queue,  first  removing 
"element"  from  any  queue  (Send  or  Timer).   */ 
#d«f 1ne  T1merAdd( element)        ( I nsert(S_T_Q, element .TimerHead, TimerHead) ) 

/*  "TtmerDel"  removes  the  selected  "element"  from  the  Timer  or  Send  queue.  */ 
#def 1ne  TimerDel (element)        ( Remove (S_T_G, element .TimerHead) ) 

/*  SendK)  adds  requested  frame  (Fbuf)  to  end  of  SendO,  updates  "tics" 
and  maintains  associated  variables.   Input  1s  "seqnum_",  the  frame's 
sequence  #  and  "framep  ",  the  pointer  to  the  Fbuf  containing  the  frame. 

v 

#def1ne  Sendl (seqnum_, f ramep_)  {  \ 

qp_  ■  &S_T_0[seqnum_] ;  /*  qp_  »  Queue  Element  for  seq  #  of  desired  Frame  */  \ 

qp~->t1cs  ■  T0_Frame;  \ 

qp~->item  ■  framep_;  /*  Link  frame  to  queue  */  \ 

framep_->seq  •  ToSeq(seqnum_) ;  \ 

SendAdd ( seqnum_ ) ;  \ 

w1ndowed++;     /*   and  in  window.  */  \ 

TRACE(sendtr,(Lp->o. H%c  INFO  %d  SOed  -  %c  to  %c.len  %d\n%.*s",  \ 

Lp->1d. seqnum_, f ramep_->f rom, f ramep_->to,  \ 

framep  ->len-FHDRslze7f ramep  ->1en-FHDRs1re, framep  ->packet));  \ 
} 

/*  SendCt  )  adds  requested  Frame  Type  to  end  of  SendO  and  updates  "tics". 

Inputs  are  "lnternal_",  the  internal  Frame  Type  variable  (like  "F1ACK") 

and  the  new  value  for  "tics"  in  the  Queue  Element. 
V 
#define  SendC( 1nternal_, t1c_)  {  \ 
qp_  »  &S_T_0[ Interna l_j ;  \~ 
qp~->t1cs  ■  t1c_;  \ 
SendAdd(  internal  ) -.  \ 

TRACE(sendtr, (Lp->o,"%c  CNTL  %c  SQed\n" , Lp-> Id, (CH)qp  ->1tem));  \ 
} 

fQe_t  *qp_:         /*  Queue  Element  pointer  used  by  SendC  &  Sendl  */ 


dun  25  05:14  1987   11nklayer.cc  Page  15 


/*  Foutput  Process  —  private  'define's  preceed  this  line.  V 
/*    Variables  (other  than  queues  declared  above)  follow...-/ 

/*  process  body  was  Hf output( 1  Ink  node.outdev, LinkP, Serv) "   */ 
/*  L1nkP  ■  adr.  of  LlnkTB~for  this  'foutput'  */ 
register  struct  LlnkTB  *Lp  -  LinkP; 

register  Fbuf  *fr;  /*  general  Fbuf  pointer  */ 

register  short  qelem;        /*  general  Frame  Queue  Element  index  */ 
register  fQe_t  *qp;  /*  general  Queue  Element  pointer  */ 

BOOL  reqOK;  ~  /*  general  Success/Fall  indicator  */ 

register  mt  1;  /"  Used  as  loop  counter,  etc.  all  over  */ 

int  windowed  ■  0;  /*  #  frames  in  window  (0  to  MAXseq)  */ 

Seq_t  last_ACK;  /"  Last  piggyback  ACK  sent  by  "framereqO"  */ 

/*  Following  used  by  "accept  framereq"  */ 
Fbuf  "sent_last_req  ■  FNULL;         /"  Fbuf  treturned  on  last  "framereq"  V 
Fbuf  *re1_next_req  «  FNULL;         /*  Fbuf  to  Rel .  on  next  "framereq"  */ 
Fbuf  local_fbuf;  /*  Private  Fbuf  (non-INFO  frames  to  dlcoin)  */ 

/*  Following  used  by  "accept  fctrl"  */ 
register  Cntl_t  req; 

/*  Following  used  by  "accept  frameln"  */ 


enum  IFrameType  f_type; 
Seq_t  1 ncom 1 ng_ACK ; 
BOOL  val id_ACK; 
BOOL  DoNack  -  True; 
BOOL  DTstate: 
Actlon_t  action; 
Int  1ncom1ng_len; 
1 nt  1 ncom 1 ng~seq ; 
1 nt  1 ncom 1 ng~f  rom ; 


/*  Used  to  store  frame  type  (Internal)  */ 

/*  ACK  1n  most  recent  received  frame  */ 

/•  True  Iff  incoming  frame  looks  valid  */ 

/*  Send  NACKs  only  while  true  */ 

/*  True  Iff  Lp->state  allows  Data  Transfer 

/"  Record  what  to  do  with  frame  V 

/*  Save  frame's  "len"  */ 

/"  Save  frame's  "seq"  (debugging)  */ 

/*  Save  "from"  for  frame's  like  STACK  */ 


char  *dn  ■  "dlco  x"; 
Lp->o  ■  wopen( ) ; 
/*  Create  Data  Link  Level  output  process  */ 
Lp->G_restart  ■  False; 
dn[strlen(dn)-1 )  ■  link  node; 
c_set name (create  dlco1nT( process  f output)c_myp1d( ) .outdev, Lp) ,dn) ; 

/*  Set-up  Queues  and  Timers  •/ 

c_setname( create  ft 1mer( (process  f output)c_myp1d( )), "f timer" ) ■ 

/*  Initialize  Queue  structures.  */ 
/*  Initial 1ze  S_T_Q.  */ 

for(  qp"S_T_Q;~qp  <  S_T_Q  +  (slzeof  S  T_Q/sizeof (f Qe_t ) ) ;  qp++  )  { 
qp->next  ■  qp->prev~«  Qnull; 
qp->t1cs  «  -1 ; 
qp->1tem  «  FNULL; 


> 

qp   ■   S_T_Q+SendHead; 
qp->next~-   qp->prev   «    SendHead; 
qp    «    S_T_Q+T1merHead; 
qp->next    -   qp->prev   •   TlmerHead 
ASSERT(TimerEmptyO) 


/T  All  elements  unlinked  */ 
/*  item  1s  empty  */ 


/*  Circular  empty  Send  Q.  */ 
/*  Timer  queue  also  empty  */ 


Initialize  the  Control 
transmitted  values. 


S_T  Q[F1ACK] .item  -  (Fbuf  *)(CH)F  ACK; 
S  T  Q[F1NACK] . Item  «  (Fbuf  *)(CH)F_NACK; 
S_T  Q[F1HEAR] . Item  -  (Fbuf  * ) ( CH)F_HEAR ; 
S_T_Q[F1START] . Item  *  (Fbuf  *)(CH)F  START; 
S_T  Q[F1STACK] . item  *  (Fbuf  " ) (CH)F~STACK ; 
S  T  Q[F1DISC]. item  «  (Fbuf  *)(CH)F  DISC; 
S  T  Q[F1AMDISC] . Item  ■  (Fbuf  *)(ChJf  AMDISC 


ASSERT(SendEmptyO); 
Frame  elements  in  S_T_Q  with  their  corresponding 


/*  Double  type  casting!  */ 


/*    Initialize  Request  queue,  if  any.   Initially  all  elements  are  on  the 
ReqFree  queue  (treated  as  a  list). 


#1f  Nbuf_req  >  0 

for ( 7-0 , qp-ReqQ ; 


1  <  Nbuf_req;  i++,qp++)  { 
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qp->next  ■  (shortM 1+1 );        /*  Point  to  next  free  element  */ 
qp->prev  ■  (short )( 1-1 ) ;        /*     and  previous  element.  */ 
qp->tlcs  ■  -1;  qp->item  -  FNULL;         /*  empty  Item  */ 
> 
/*  ReqO  "request"  elements  linked  together,  now  tie  up  the  loose  ends  */ 

qp  ■  ReqO+ReqFree;  /*  Link  freellst  Head  to  "request"  elements  */ 

qp->next  ■  0;  /*  ..Forward  link  to  first  free  element  (0)  */ 

ReqO[0].prev  ■  ReqFree;      /*  ..Back  link  to  freellst  Head  */ 
qp->prev  ■  Nbuf  req-1;       /*  ..Backward  link  to  last  free  element  */ 
ReqQ[ Nbuf _req- lj. next  «  ReqFree;  /*  ..Fwd.  link  to  freellst  Head  */ 
qp->t1cs  ■  -1;  qp->1tem  «  FNULL; 

qp->next  ■  (qp  ■  ReqO+ReqHead)->prev  ■  ReqHead;      /'    Req  Q.  empty  V 

/*  Above  works  —  trust  me!  */ 
qp->tlcs  •  -1;  qp->1tem  «  FNULL; 
ASSERT(ReqEmptyO);   ASSERT(  !ReqFul  1(  )): 
#end1f  Nbuf_req  >  0 

/*  End  of  queue  Initialization  */ 

/*  Set  protocol  variables  to  initial  values.   "state"  Initialized  by  ma1n()  */ 
Lp->buffered  »  0; 

Lp->ExpectedF  -  0;  Lp->ExpectedA  »  0;  Lp->NextF  «  0; 
last_ACK  ■  Lp->ExpectedF ;    /*  This  assignment  forces  ACK  time-out  to 

send  an  ACK,  since  'last_ACK"  !■  "ExpectedF-1 ■  */ 
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LOOP  /*  Real  Body  of  'f output'  */ 

PICTURE(nextlnseq.Lp->ExpectedF); 
PICTURE(nextoutseq.Lp->NextF); 
select  { 

(Lp->buffered  <  MAXbuf fered) : 

/*  Accept  only  if  can  be  buffered  */ 
accept  f wdmsg( Pr lor 1 ty ,  pktp ,  from ,  to ,  1  en ,  net_type )  { 

/*  Validate  request.   If  low  priority  (not  Pr1or1ty<«FPrior  «>  forwarding  from 
another  node),  reject  1f  Link  Is  not  CONNected.   If  higher  priority,  allow 
forwarding  while  also  In  "waitlngDISC" .   If  number  of  remaining 
buffers  (MAXbuf fered-Lp->buf fered)  doesn't  exceed  Priority,  reject  for 
lack  of  buffers. 
V 

reqOK  ■  False;       /*  Assume  request  falls  */ 

1f(  Lp->state  I"  L_C0NN  &&    Priority  >  FPMor  )  treturn  E  NotConn; 

1f(  Lp->state  !■  L_C0NN  &&  Lp->state  !«  L_wa1 t ingDISC  ) 

treturn  E  NotConn;   /*  Can't  accept  If  link  is  down  "/ 
if(  (MAXbuffefed  -  Lp->buf fered)  <  Priority  )  treturn  E_NoBuffs; 
reqOK  -  True;       /*  Nothing  but  Success  below.  V 

/*  Store  packet  1n  a  FrameBuffer  (Fbuf)  &  allow  requestor  to  continue.  */ 
f r  »  Serv. getF( ) ; 

/*   Copy  packet  to  fr,  add  from,  len,  to,  net_type   */ 
memcpy(f r->packet , pktp, len) ; 
fr->from  ■  from;    fr->to  ■  to; 
fr->len  ■  len; 
ft — >net_type  •  net_type; 
treturn~E  OK; 
> 
1f(  reqOK  «  True  )  { 

Lp->buf fered++ ;  /*  FrameBuf  taken  —  count  it.*/ 

fr->len  +«  FHDRsIze;        /*  Now  add  in  header  size  */ 
/*  Add  new  frame  to  SendO  (1f  room  in  transmit  window)  or  to  RequestO. 
All  frame  items  except  "ack"  and  "seq"  are  already  filled  in. 
Sendl ( )  fills  1n  "seq"  for  the  SendO  case:  "seq"  is  ignored  on  RequestO. 
V 

1f(w1ndowed  <  Nwlndow)  {    /*  If  room  in  window,  */ 

ASSERT(unOued(Lp->NextF));  /*  and  element  1s  Idle,  */ 
SendI(Lp->NextF.fr);     /*  then  add  to  SendO.  */ 

/*  . . ( Increments  "windowed" )  */ 
Lp->NextF  ■  ModInc(Lp->NextF);   /*  Seq.  0    for  next  new  Frame  */ 
) 
#1f  Nbuf_req  >  0 

else  {  /*  or  window  closed,  add  to  RequestO.  */ 

ASS£RT(  !  ReqFulK)  ); 

S  T_0[  ReqAddO  ].1tem  -  fr;  /*  Get  elem.,  link  Fbuf  to  RqO  V 
TRACE(sendtr,  (Lp->o,  B'/.c  INFO  RQed  -  %c  to  %c,  len  %d\n%.*s", 
Lp->1d, fr->f rom.fr- > to.fr- > len- FHDRsIze. 
f r-> 1 en-FHDRs 1 ze , f r->packet ) ) ; 
} 
#else  Nbuf_req  >  O 

else  {  /*  or  window  closed  and  no  RequestO,  so 

"accept  fwdmsg"  shouldn't  have  accepted!  •/ 
errmsg( "f output : IE1 " .buffered) ; 
} 
#end1f  Nbuf  req  >  0 
>   " 
or 
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accept  fetrl (Req)  { 
reqOK  =  True; 
req  *  Req ; 
1f(  req  «■  reqDISC  &&  Lp->state  »=  L_CONN  ) 

treturn  E_OK; 
1f(  req  «  reqCONN  &&  Lp->state  ■■  L_DISC  ) 

treturn  E_OK; 
reqOK  >  False; 
treturn  E_WrongState; 

/*  'treturn'  resumes  execution  here, 
user  runs  while  request  completes  */ 
1f(reqOK  »»  True)  { 

1f(  req  «  reqDISC  )  {       /*  Part  of  LINK  CONTROL  Protocol  */ 
Lp->state  =  L_walt1ngDISC; 
Lp->attempts  ■  0; 
1f(  Lp->buffered«0  )  {  /*  Apply  "wDISC"  transition  logic  */ 

SendC(F1DISC.T0_DISC);       /*  0  DISC,  start  timer  */ 

Lp->recelvedDISC  -  Dwaltmg; 
)  else  {  /*  ..else  just  start  DISC  timer  */ 

S_T_Q[T1merAdd(F1DISC)].t1cs  -  TO  DISC; 

Lp->rece1vedDISC  ■  Dfalse; 
} 
>  else  1f(req  «  reqCONN)  { 

Lp->state  ■  L_walt1ngC0NN; 

Lp->attempts  ■  0; 

Lp->ExpectedA  «  Lp->NextF  «  O; 

Lp->ExpectedF  •  0;       /*  Altered  by  Incoming  STACK  msg.  */ 

1ast_ACK  ■  0;  /*  See  Initialization  code  for  reason  */ 

SendC(F1START,T0_START);  /*  Q  START  for  xmlssion,  start  timer  */ 


/*  End  Part  of  LINK  CONTROL  Protocol  */ 
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(  !  SendEmptyO  ):  /*  Only  If  something  on  SendQ  . . .  */ 

accept  framereqO  { 

/'*  Retrieve  next  frame  to  be  transmitted  from  SendO .   If  the  element  1s  for 
an  INFO  frame,  "Item"  is  pointer  to  the  Fbuf  containing  the  frame.   All 
frame  Items  except  "ack"  are  already  filled  in.   If  control  frame  element, 
format  a  frame  in  "local_fbuf ■ .   Queue  element  "item"  contains  the  value 
of  "seq"  to  transmit.   For  all  frames.  Insert  the  current  value  for  the 
"ack"  piggyback  ACK .  which  is  "ExpectedF-1 H  (the  last  good  frame  received). 
For  STACK,  also  insert  "ExpectedA"  (the  sequence  number  of  the  next  outgoing 
INFO  frame)   Into  "from"  field.   All  values  of  "ack"  are  biased  by  using 
ToSeqO,  as  1s  the  "seq"  field  1n  INFO  frames. 
V 

qelem  ■  SendGet();   /*  Get  next  element  to  transmit.  */ 
#1f  0  /*  Change  0  to  1  to  eliminate  redundant  HEAR  (for  purists,  see  below.)  */ 
1f(  qelem  «  F1HEAR  &&  (!  SendEmptyO)  )  {  /"  Throw  away  HEAR  if  */ 
qelem  -  SendGetO;  /*  other  SendO  entries  */ 

#end 1 f 

qp  ■  &S_T_Q[  qelem  ]; 

fr  ■  qp->item;  /*  Get  frame  pointer  or  Control  code  */ 

last_ACK  -  ModDec(Lp->ExpectedF) ;    /*  "ExpectedF- 1 "  will  be  piggy- 
back ACK.   Used  by  uft1me()  &  frameinO"  "/ 
if(  qelem  <-  MAXseq  )  {      /*  If  INFO  element,  just  set  up  "ack"  */ 
ASSERT(fr>-FMIN) ;        /*  ..since  "seq". etc.  done  by  SendlO  */ 
fr->ack  »  ToSeq( last_ACK);  /*  "ExpectedF-1 ■  */ 

sent_last_req  -  fr;      /*  Indicate  frame  in  use  by  requestor  •/ 
)  else  {  /*  Else  Control  element,  build  frame  */ 

ASSERT(fr<FMIN); 

local_fbuf .seq  ■  (CH)fr;         /"  Store  xmltted  frame  type  */ 
local  fbuf. Ten  ■  Lctl;   /*  Control  frames  are  short  (usually)  */ 
local_fbuf .ack  ■  ToSeqdast  ACK); 

sw1tch<  (char)fr&CH_MASK  )  7    /*  Do  type-dependent  stuff  */ 
case  (char)F_STACK&CH_MASK: 

local_fbufTf rom  ■  Lp->ExpectedA; 
local~fbuf . len  ■  Lctl_STK; 
break? 
default:       /*  Handle  non-exceptional  frame  types  */ 
/•  Empty  V 
break; 
> 

fr  »  slocal_fbuf;        /"  Address  of  Fbuf  to  "treturn"  */ 
sent_last_req  ■  FNULL;   /•  Indicate  local  frame  in  use  V 

treturn  fr;         /*  Return  frame  buffer,  let  requestor  run.  */ 

/*  If  frame  is  to  be  "timed",  the  "tics"  field  must  be  positive.  */ 
if(qp->tics  >  0)  { 

TimerAdd(qelem);  /*  Start  frame  timer  */ 

/*  Release  any  non-local  frame  that  was  in  use  in  previous  rendevous, 

but  is  no  longer  in  "window"  and  thus  can  be  released  to  the  Fbuf  pool. 
Note:   "rel_next_req"  is  set  by  frameinO  when  the  attempt  to  release  an 
Fbuf  Is  blocked  by  the  Fbuf's  address  being  in  "sent_last  req",  implying 
'dlcoln'  could  still  be  transmitting  from  that  Fbuf.   This  code  handles 
the  release  of  such  an  Fbuf,  since  'dlcoln'  is  always  finished  with  a 
previous  Fbuf  during  "f ramereq( ) " . 

1f(  rel_next_req  !-  FNULL  )  { 
Serv. rel F(rel  next  req) ; 

rel_next__req  »  FNULL;        /*  Frame  released  */ 
Lp->buffered — ;  /*   and  count  adjusted.  */ 

/*  Start  the  HEARtbeat  send  timer  if  SendO  is  empty.  It  may  already  be  running 
(on  T1merQ>;  if  so,  just  reset  "tics"  to  new  interval,  otherwise  add  HEAR  to 
TlmerQ.  If  nothing  is  sent  before  the  timer  expires,  a  HEARtbeat  frame  will 
be  added  to  the  SendO,  unless  SendO  already  has  an  entry. 

Note:   If  HEAR  is  placed  on  SendO  and  another  frame  1s  added  to  SendO  prior 
to  HEAR's  transmission,  HEAR  will  NOT  be  removed  from  SendQ  (even  though 
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having  HEAR  on  SendO  with  another  frame  is  ..well..   redundant  and 
wasteful).   This  1s  a  low  probability  situation,  since  it  would  imply  HEAR 
timed-out  and  was  entered  on  SendO  just  before  another  SendO  entry  was 
made,  but  before  framereqO  could  occur.   To  avoid  sending  HEAR  in  this 
case  (which  hurts  only  throughput  (?)  on  a  previously  idle  channel),  HEAR 
could  be  thrown  away  at  the  beginning  of  framereqO  IF  SendO  has  another 
entry  on  it.   [The  code  1s  provided  above,  but  turned  off.] 
In  time-out  processing  (ftimeO),  HEAR  timeout  is  handled  last  to  avoid 
putting  HEAR  on  SendO  and  then  adding  another  entry  to  SendO  as  the  result 
of  another  type  of  time-out  during  the  same  entry  to  ft1me(). 
*/ 

if(  unQued(FIHEAR)  )  {  /*  If  HEARtbeat  not  on  Queue.  */ 

TimerAdd(FIHEAR);  /*  ..put  It  on.  */ 

> 

S_T_0[F1HEAR] .tics  -  TO_HEAR;    /"  Restart  the  timer  */ 
/*  (HEAR  cannot  be  on  the  SendO  at  this  point,  because  it  is  only  added  to  the 
SendO  when  SendO  is  empty  and  nothing  is  ever  linked  in  front  of  an  existing 
entry  on  the  SendO.   The  SendGetO  above  would  have  removed  HEAR  from  SendO 
had  it  been  there.   If  the  queuing  strategy  changes  and  HEAR  could  appear 
elsewhere  on  SendO.  the  above  code  will  reset  "tics"  to  the  value  1t 
already  has  and  thus  is  harmless.) 
V 

TRACE(reqtr, (Lp->o, "%c  Req  for  frame  %c\n" . Lp->id, f r->seq) ) ; 
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accept  framein( infr)  { 
reqOK  -  False; 
action  «  A_IGNORE; 


/*  True  only  If  there  was  an  Incoming  frame  */ 
/*  Normal  'treturn'ed  action,  except  for  INFO  */ 


"1nfrM  mm    FNULL  If  'dlciln'  has  not  detected  a  frame  within  the  HEARtbeat 
failure  time  Interval.   Complain  to  someone  and  tell  'finput'  to  Ignore  1t. 

1f(  infr  «  FNULL  )  { 

1f(  Lp->state  --  L  CONN  )  {      /*  Complain  only  if  "stable"  •/ 
wprihtf  (Lp->i,"%c  \007   HEARTBEAT  f a1 1 ure t ! \nH , Lp->1d) ; 


treturn  A  IGNORE; 


/*  But  there  wasn't  an  Incoming  frame  */ 


else  1f(  1nfr  <  FMIN  ) 
wprintf (Lp->1 


{ 


} 


/*  finput  reporting  error  (bad  frame)  */ 
%c  \007   Incoming  frame  error  %d\n", 
Lp->1d,(1nt)1nfr); 
treturn  A_IGNORE;        /*  But  there  wasn't  an  incoming  frame  */ 


/* 


V 


/* 


ASSERT( 1nfr>«FMIN); 

reqOK  ■  True;  /*  There  really  was  an  incoming  frame  */ 

i ncom 1 ng_seq  -  (1nt ) inf r->seq;       /*  Save  "seq.len"  for  debug.  */ 

incom1ng_len  ■  ( int ) 1nf r->len; 

DTstate  «  (  Lp->state  •»  L_CONN  ||  Lp->state  --  L_wattingDISC  ); 
"  inf r"->val id  frame  buffer.   First  determine  1f  piggyback  ACK  1s  valid. 
If  not.  Ignore  the  data,  but  continue  to  process  frame.   This  1s  an  error- 
checking  trade-off  and  one  could  argue  the  entire  frame  should  be  ignored. 


1  *  (int)1nfr->ack  -  (CH)F  INF_0; 
1f(  1  >-  0  &&    1  <=  MAXseq  7  < 

1 ncom 1 ng  ACK  ■  1 ; 

val 1d  ACK  ■  True; 
>  else  { 

Incoming  ACK  ■  ( 1nt ) inf r->ack; 

val id  ACK  ■  False; 
) 


/*  If  properly  biased,  */ 

/*  .  .  1  is  an  OK  ACK.  */ 


/*  Save  for  debugging  */ 


Now  determine  frame's  type  and  handle  the  minimum  verification  needed  before 
allowing  'finput'  to  continue  (via  'treturn').   Note  that  'dlciln'  has 
already  partially  validated  the  frame  (m1n1mun  length,  checksum,  etc.). 
Note:   Again  the  decision  for  leniency  has  been  made.   If  "len"  1s  at  least 
as  large  as  the  minimum  for  the  type  of  frame,  then  "len"  Is  considered 
'verified.'   This  allows  for  a  downward  compatibility  1n  that  future  uses 
of  a  type  of  frame  could  send  more  information,  but  tolerate  the  minimum 
size  as  Input  from  other  nodes. 

Check  for  INFO  first,  since  most  frames  should  be  INFO  */ 


1 


/*  If  INFO, 

r 


/•  Bad  INFO  frame  */ 


(1nt)1nfr->seq  -  (CH)F  INF_0 
1  >"  0  &&  1  <*  MAXseq  7  < 
f  type  -  F1INF0; 
1f(  1nfr->len  <  FHDRsize  )  { 

action  ■  A  BADframe; 
} 
else  1f(  DTstate  &&  (Seq_t)i 

action  •  A_ROUTEMSG;  /* 
}  else  {      /*  Out  of  sequence  or  bad  state 

/*  EMPTY  -  action  already  A_IGN0RE  */ 


"1"  is  */ 
binary  seq. 


*  V 


Lp->ExpectedF  )  { 
DTstate  &  Frame  In  sequence  */ 

throw  away  */ 


/* 


> 


If  not  an  INFO,  use  'switch'  to  determine  internal  frame  type  and  action, 
else  sw1 tch( 1ncom1ng_seq&CH_MASK)  { 
case  ( 1nt)F_ACK&CH_MASK; 

/*  Minimum  "len"  verified  by  'did  in',  "ack"  already  aone  */ 

f_type  -  F1ACK; 

break; 
case  ( int)F_HEAR&CH_MASK: 

/"  Minimum  "len"  verified  by  'dlciln' 

f_type  ■  F1HEAR; 

break; 
case  (int)F_NACK&CH_MASK: 

/*  Minimum  "len"  verified  by  'dlciin' 


"ack"  already  done  */ 


"ack"  already  done  */ 
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f_type  =  FiNACK; 
break; 
case  ( 1nt)F_START&CH_MASK: 

/*  Minimum  "len"  verified  by  'dlelln',  "ack"  already  done  "/ 
f_type  =  Fi START; 
break; 
case  ( 1 nt ) F_STACK&CH_MASK : 

/*  Minimum  "len"  is  Lctl_STK,  "ack"  already  done  */ 

f_type  «  F1 STACK; 

1f(  1ncom1ng_len  <  Lctl_STK 

||  ( 1ncom1ng_f rom  ■  ( 1nt ) 1nf r->f rom)  >  MAXseq)  { 
action  »  A  BADframe; 
> 

break; 
case  ( int)F_DISC&CH_MASK: 

/*  Minimum  "len"  verified  by  'did  in',  "ack"  already  done  */ 
f_type  -  F1DISC; 
break; 
case  (lnt)F_AMDISC&CH_MASK: 

/*  Minimum  "len"  verified  by  'did  In',  "ack"  already  done  */ 
f_type  ■  F1AMDISC; 
break; 
default:  /*  Case  of  the  "unknown  frame  type"  */ 

action  ■  A_BADframe; 
break ; 
> 

1f(  action  «  A_BADframe  )  reqOK  «  False;    /*  Don't  process  BAD!  */ 
treturn  action;  /*  Done  with  frame  -  return  "action"  */ 

>  /*  end  of  "frameinO"  rendevous  */ 

/*  Now  that  'flnput'  has  been  told  what  to  do  with  the  incoming  frame, 
'foutput'  needs  to  finish  up  updating  any  protocol  or  state  variables, 
as  well  as  adding  any  appropriate  responses  to  the  SendO. 

First,  handle  the  piggyback  ACK  since  it  could  eliminate  frames  currently 
on  the  TlmerO  or  SendO  and  give  a  more  accurate  view  of  the  other  node's 
state.   Also,  1t  happens  to  be  the  first  thing  handled  by  all  incoming 
frame  states  in  the  Data  Transfer  state  diagrams. 

1f(  valid  ACK  I«  False  )  {      /*  Remove  "ack"ed  frames  from  window  */ 
while!  BETWEEN* Lp->ExpectedA, 1 ncoming_ACK, Lp->NextF )  )  { 
/*  Remove  from  either  Queue,  stop  timing,  and  get  pointer  to  frame  Buf .  */ 
fr    ■  S  T_Q[T1merDel(Lp->ExpectedA)] . Item; 

ASSERT(fr>«FMIN);        /*  Must , must .must  point  to  Fbuf  */ 
windowed — ; 
/*  Frame  removed  from  window,  now  release  it's  FrameBuf  (or  defer  If  'dlcoln' 
could  be  using  it  —  see  "f ramereq( ) "  comments). 

1f(  fp  »■  sent_last_req  )  {  /*  IF  'dlcoln'  has  this  frame,  */ 

rel  next_req  -  fr;  /*  ..let  "framereqO"  release  Fbuf  */ 

}  else  T 

Serv.relF(fr);  /*  ..else  I'll  do  1t  */ 

Lp->buffered — ;  /*  ....and  count  1t.  */ 

> 

Lp->ExpectedA  »  ModInc(Lp->ExpectedA) ; 

)  /*  end  "1f(  val1d_ACK. . . "  V 
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/*  Don't  do  any  further  processing  (except  ReqQ-related)  1 f  t reqOK  V 
1f(  reqOK  ■"  True  )  { 

/*  Apply  a  test  for  the  "AMDISC"  transition  here,  instead  of  putting  the  test 

m  each  of  the  'case's  below.   Requires  state  ■«  DISC. 
V 

if(Lp->State  «  L_DISC  &&  f_type  !«  F1START  &&  f  type  !-  F1AMDISC)  { 

SendC(FIAMDISC.O); 
}  else  switch* (1nt)f  type)  { 
case  (1nt)F1INF0: 

1f(  IDTstate  )  break;        f*    Can't  process  in  this  state  */ 
1f(  action  «  A_ROUTEMSG  )  {  /*  Message  sent  to  Net.  layer,  */ 
/*  Start  the  ACK  timer,  since  an  incoming  INFO  was  accepted.  */ 
1f(  SendEmpty( )  )  { 

qp  »  &S_T_Q[F1ACK];  /*  Get  ACK  pointer  */ 

iff  qp->next  »■  Qnull  )  < 

T1merAdd(F1ACK);        /*  Add  to  TimerO  1f  needed  */ 
qp->tics  »  TO  ACK;       /*  Set  ACK  timer  •/ 
> 
else  1f(  last  ACK  ■■  ModDec(Lp->ExpectedF )  )  { 

qp->t1cs  »  TO  ACK;       /*  Reset  ACK  timer  */ 
} 
} 
DoNack  ■  True;  /*  Allow  future  NACKs  */ 

/*  (Incr.  ExpectedF  after  "last_ACK"  check  is  done!)*/ 
Lp->ExpectedF  «  ModInc(Lp->ExpectedF ) ; 
) 

el  se  { 
/*  INFO  wasn't  sent  to  Net.  layer  (for  whatever  reason).  */ 

1f(  DoNack  !-  False  )  {  /*  If  first  error  for  this  ExpectedF.  */ 
SendC(FiNACK.O);     /*  ..send  a  NACK  and  */ 
DoNack  «  False;      /*  ..don't  let  it  happen  again!  */ 
} 
> 

break; 
case  ( 1nt)F1ACK: 

/*  Currently  does  nothing  special  */ 
break; 
case  ( int)F1HEAR: 

/*  Currently  does  nothing  special  •/ 
break; 
case  (mt)FiNACK: 

1f(  IDTstate  )  break;        /"  Can't  process  in  this  state  */ 
/*  Resend  frames  from  ExpectedA  up  to  NextF.  if  any  frames  1n  window.  */ 

for(  qelem  ■  Lp->ExpectedA,  1»0  /*  1  counts  frames  */ 

;  qelem  ! ■  Lp->NextF 
:  qe 1  em-Modi nc ( qe 1  em ) ,  1 +  * )  { 
SendAdd(qelem) ;  /*  Removes  from  existing  Queue  */ 
S  T  Q[qelem] . t ics  ■  TO  Frame;    /*  Reset  timer  */ 
> 
/*  Should  retransmit  exactly  'window'  frames  */ 
ASSERT(  1«w1ndowed) ; 

Lp->G  restart  ■  True;        /*  Tell  'dlcoln'  to  abort  xmisslon  */ 
TRACETfrintr.(Lp->1 ,  ""Ac   NACK  received  -  re-Send  %d  up  to  %d\n", 

Lp->id,Lp->£xpectedA,Lp->NextF)); 
break; 
case  ( 1nt)F1START: 
Lp->State  ■  L_C0NN; 
SendC(FISTACK.O); 

/*  "f ramereq( )■  will  add  "from"  set  to  "ExpectedA" .  */ 
/*  If  in  a  Data-Transf er-al lowed  state,  "winddwed"  and  "NextF"  are  (assumed) 
valid.   However,  the  frames  in  the  'window'  should  be  forced  back  onto  the 
SendO  (after  the  STACK  frame)  like  an  incoming  NACK.   If  not  in  a  DTstate, 
then  "windowed"  and  "NextF"  are  initialized,  and  any  INFO  frames  are 
removed  from  any  Queues . 
V 

1f(  DTstate  )  < 
/*  Resend  frames  from  ExpectedA  up  to  NextF,  1f  any  frames  In  window.  */ 

for(  qelem  ■  Lp->ExpectedA,  1»0         /*  1  counts  frames  */ 
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;  qelem  !■  Lp->NextF 
:  qelem»ModInc(qelem) ,  1++)  { 
SendAdd(qelem) ;      /*  Removes  from  existing  Queue  */ 
S  T_Q[qelem] . t ics  -  TD  Frame;        /*  Reset  timer  V 
> 
/•  Should  retransmit  exactly  'window'  frames  V 
ASSERT  (  1  «w  1  ndowed )  ; 

Lp->G  restart  -  True;    /*  Tell  'dlcofn'  to  abort  xmlsslon  */ 
TRACE(fr1ntr,(Lp->1 , "%c   START  received  -  re-Send  Sid  up  to  %d\n", 
Lp->1d,Lp->ExpectedA,Lp->NextF)); 
>  else  < 

ASSERT  (Lp->buffered—0); 

for(  qelem  ■  0;  qelem  <  NUMseq;  qelem++  )  { 
1f(  0ued( qelem)  )  { 

TlmerDel (qelem) ;         /*  Remove  from  either  Queue  V 

) 

Lp->NextF  »  Lp->ExpectedA  •  0; 

windowed  ■  0: 

TRACECf r1ntr.(Lp->1 , -%c  START  rece1ved\n",Lp->1d)); 

Lp->ExpectedF  -  0;   /"  Could  be  modified  by  Incoming  STACK  */ 
1f(  Oued(FISTART)  )  {  /*  Del.  Q'ed  START  (stop  "START  Timer")  */ 

TlmerDel (F1 START); 
) 
1f(  Qued(FIDISC)  )  <  /*  Del.  Q'ed  DISC  (stop  "DISC  Timer")  */ 

TlmerDel (F1DISC); 
} 

break; 
case  ( 1nt)F1STACK: 

1f(  Lp->state  !-  I__wa  1 1 1  ngCONN  )  break;  /*  Ignore  If  unexpected  V 
Lp->state  -  L_C0NN; 

Lp->ExpectedF  ■  (Seq  t ) 1ncoming_f rom;        /*  Already  verified  V 
1f(  Qued(FISTART)  )  T  /*  Del.  Q'ed  START  (stop  "START  Timer")  */ 

TlmerDel (F1START); 
} 

break; 
case  (1nt)F1DISC: 

switch  (Lp->state)  (        /*  DISC  response  depends  on  state  •/ 
case  (  i  nt )  L_wa  1 1 1  ngCONN : 

Lp->state  »  L_DISC;  /*  "stayDISC"  transition  */ 

SendC(FIAMDISC.O);  /*  Send  AMOISC,  never  timed  */ 

if(  Oued(FISTART)  )  {  /*  Del.  Q'ed  START  (stop  "START  Timer")  "/ 

TlmerDel (Fi START); 
) 

wprintf (Lp->o. "%c  CONN  attempt  falls  \007\007\n" , Lp->1d) ; 
break; 
case  ( 1 nt ) L_C0NN : 

Lp->state  -  L_wa1tingDISC;       /*  "DISCL"  transition  */ 
Lp->attempts  •  0; 
Lp->receivedDISC  •  Dtrue; 

S_T_Q[T1merAdd(F1DISC)].t1cs  -  T0_DISC;  /*  Start  "DISC  timer"  */ 
break ; 
case  ( int )L-wait1ngDISC: 

if (Lp->buffered  --  0)  <         /*  "toDISC"  transition  */ 
Lp->state  -  L_DISC;         /*  Finally  Disconnected!  */ 
SendC(FIAMDISC.O); 
if(  Oued(FiDISC)  )  {        /•  Stop  DISC  timer  */ 

TimerDel(FIDISC); 
} 
Lp->ExpectedF  ■  Lp->ExpectedA  •  Lp->NextF  -  0; 

break; 
case  (1nt)L_DISC: 

/*  "AMDISC"  transition  handled  below  */ 

break; 
default:  errmsgl "foutput :IE5", ( int )Lp->state) ;  /*  Unknown  state  "/ 

break; 
case  (int)FIAMDISC: 
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1f(Lp->state  !-  L_wait IngDISC)  break;   /*  Ignore  other  states  */ 
If (Lp->buffered  »«  0)  {  /*  "toOISC"  transition  */ 

Lp->state  »  L_DISC;  /*  Finally  Disconnected!  */ 

SendC(FIAMDISC.O); 

1f(  Ouea(FIDISC)  )  <     /*  Stop  DISC  timer  */ 
T1merDeKF1DISC); 

> 

Lp->ExpectedF  •  Lp->ExpectedA  -  Lp->NextF  ■  0; 
) 

break; 
default:  errmsg("f output :IE4" , ( 1nt)f_type) ;    /*  Unknown  frame  type  */ 

}  /*  end  "1f(  reqOK...)  ...  switch..."  */ 

/*  Now  It's  time  to  see  1f  one  of  the  special  tests  1n  the  "wa1 t 1ng_DISCH  state 
can  be  applied.   These  cases  are  the  "WDISC"  and  "toDISC"  transitions  from 
the  "Report",  and  only  apply  If  "state«L_wai  t  IngDISC"  AND  Hbuf  fered"0" . 

1f(Lp->state  ■■  L_wa1t1ngDISC  &&  Lp->buffered  "  0)  < 

1f(  Lp->rece1vedDISC  "-  Dtrue  )  (    /*  "toDISC"  transition  */ 
Lp->state  -  L_DISC;  /*  Finally  Disconnected!  */ 

SendC(FIAMDISC.O); 
1f(  Oued(FIDISC)  )  <    /*  stop  DISC  timer  •/ 

TlmerDel(FIDISC); 
} 

Lp->ExpectedF  -  Lp->ExpectedA  -  Lp->NextF  »  0; 
>  else  if(  Lp->rece1vedDISC  --  Dfalse  )  <    /*  "WDISC"  transition  */ 
SendC(F1DISC.T0_DISC);   /*  Send,  then  restart  timer  */ 
Lp->receivedDISC  »  Dwalting;     /*  (Inhibits  more  DISCS  here  V 

> 

/*  Now  It's  (finally)  time  to  see  If  any  more  frames  can  be  added  to  the 

transmit  window  from  the  ReqO,  but  only  if  we're  in  a  DTstate. 
V 

#1f  Nbuf  req  >  0 

Tf(  DTstate  --  True  &&  !ReqEmpty()  )  ( 

while!  !ReqEmpty()  &&  windowed  <  Nwlndow  )  { 

ASSERT(unOued(Lp->NextF));  /*  window  elem.  must  be  Idle  */ 

qp  -  &S_T_0[  ReqGetO  ];  /*  Get  next  element  */ 

Sendl (Lp->NextF,qp->1 tern) ;  /*  (Increments  "windowed")  •/ 

Lp->NextF  -  ModInc(Lp->NextF);   /*  Seq.  *    for  next  new  Frame  */ 

> 
#end1f  Nbuf_req  >  0 
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accept  ft1me()  {  /*  Time  'til  next  event  */ 

/*  EMPTY  */ 
>       /*  End  rendevous  -  allow  timer  to  continue  */ 
/*  Scan  Timer  Queue  decrementing  "tics"  &    indicating  any  t1med_out  elements  */ 

{  /*  This  block  handles  all  Data  Transfer  and  Link  Control  TIMEOUTS  */ 
short  qeleml;        /"  Temp,  element  pointer  */ 
int  t1meout_INF0  ■  0,  timeout_ACK  ■  0,  timeout  HEAR  «0, 

t1meout~START  «  O,  t1meout_DISC  »  0  ;    /*  Inlt.  indicators  */ 
for  (  qelem--  S_T_Q[TimerHead]7next 
;  qelem-!-  TimerHead 
;  qelem  *  qeleml  )  { 
qeleml  »  S_T_Q[qelem] . next j  /*  Get  pointer  to  following  el  em.  */ 
/*  T1merDe1-()  destroys  "next"  */ 
/   Decrement  "tics"  and  remove  any  timed-out  elements,  bumping  indicators.  */ 
1f(  — (S_T_0[qelem] .tics)  <  0  )  { 

TlmerDel (qelem) ;     /*  Remove  element  from  TimerQ  */ 

1f{  qelem  <»  MAXseq  )  t 1meout_INF0++ ; 

else  1f(qelem  «■  F1ACK)  timeout  ACK++; 

else  1f(qe1em  ■■  F1HEAR)  timeout  HEAR++; 

else  iftqelem  "  F1START)  t 1meout_START++; 

else  iffqelem  ■■  F1DISC)  timeout  DISC++; 

else  errmsg( "f output : IE3" .qelem) ; 

>    /•  end  "for"  */ 

/*  FRAME  Timeout  Processing  */ 

1f(  timeout_INFD  >  0  )  { 

ASSERT(w1ndowed>0):      /*  Must  be  some  frames  in  window  */ 
/*  Resend  frames  from  ExpectedA  up  to  NextF.  */ 

for(  qelem  «  Lp->ExpectedA,  i*0         /*  1  counts  frames  */ 
;  qelem  !■  Lp->NextF 
;  qelem-Modlnct qelem) ,  i++ )  { 
SendAdd( qelem) ;      /*  Removes  from  existing  Queue  */ 
S_T_Q[qelem] . tics  -  T0_Frame;        /*  Reset  timer  */ 

/*  Should  retransmit  exactly  'window'  frames  */ 
ASSERT( 1»-windowed) ; 
TRACE(totrace. (Lp->o. 

"%c   T.O.  INFO  frames  -  re-Send  %d  up  to  %d\n", 
Lp->1d,Lp->ExpectedA,Lp->NextF)); 

/*  START  Timeout  Processing  */ 

1f(  t1meout_START  )  { 

1f(  Lp->  attempts  <  MAXSattempts  )  {     /*  Retry  START  */ 
Lp->attempts++; 
SendC(F1START,T0_START);     /*  Send  START,  then  time  1t  */ 

®lse  {  /*  Too  many  retries,  CONN  request  fails  */ 

Lp->state  »  L  DISC;         /*  "stayDISC"  transition  */ 
SendC(F1AMDISC,0);  /*  Send  AMDISC,  never  timed  */ 

/*  START  timer  already  stopped  (above)  */ 
wprintf (Lp->o,"%c  CONN  attempt  fails  \007\007\n" . Lp->1d) ; 

} 

/* DISC  Timeout  Processing */ 

1f(  tlmeoutJDISC  >  0  )  { 

1f(  Lp->buffered  •»  0  &&  Lp->recei vedDISC  «■  Dtrue  )  { 

SendC(FiAMDISC.O);   /*  Send  AMDISC,  we're  disconnected  V 

Lp->state  «  L_DISC; 

Lp->ExpectedF  ■  Lp->ExpectedA  ■  Lp->NextF  ■  0; 

eTse  {  /*  Timeout,  but  not  ready  to  disconnect.  */ 

1f(  Lp->attempts  <  MAXDattempts  )  {  /*  Retry  DISC  */ 
Lp->attempts++ ; 
/   The  DISC  timer  times  total  time  from  DISC  request,  tout  DISC  is  not  actually 
sent  until  all  buffered  INFO  frames  are  successfully  transmitted  (ACKed)   */ 
1f(  Lp->buffered««0  )  ( 

/*  Implies  receivedDISC  !■  true  (see  above)  */ 
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) 


SendC(F1DISC,T0_DISC);      /*  Send  and  retime  */ 
e  { 


/*  Don't  send,  but  retime  */ 

S  T  Q[T1merAdd(F1DISC)] .tics  *  TO  DISC; 
} 

} 

else  {      /*  Too  many  attempts  —  DISC  request  falls  */ 

Lp->state  -  L  CONN; 

SendC(FISTARTTo);       /*  Send  START,  no  timing  •/ 

/*  (When  SendEmpty(),  HEAR  timing  will  start.)*/ 

wprlntf (Lp->o. "%c   DISC  attempt  fai ls\007\007\n" . Lp->1d) ; 

>       /*  end  "1f(  buffered  . . . "  else  case  */ 

/* ACK  Timeout  Processing */ 

/*  ACK  1s  placed  on  the  TlmerQ  when  an  Incoming  frame  must  be  ACKed  and  there 
are  no  entries  on  the  SendO.   (SendO  entries  all  carry  a  piggyback  ACK). 
On  time-out,  ACK  should  be  added  to  SendO  only 

1)  1f  SendO  is  empty, 

2)  the  Link  is  not  In  the  DISC  state  (on  transitions  to  DISC  state,  ACK  1s 
not  removed  from  TlmerQ  —  it  eventually  times  out.  No  harm  is  done  If 
DISC  state  is  entered  and  exited  while  ACK  Is  timing  out,  since  at  most 
it  will  cause  an  extra  ACK  to  be  transmitted.)  and 

3)  no  previous  frame  was  sent  with  the  current  "ExpectedF-1 "  piggyback  ACK. 
This  last  condition  is  determined  by  the  "last_ACKM  variable,  and  can  occur 
only  1f  another  frame  has  not  been  added  to  SendO  and  transmitted  during  the 
time  the  ACK  1s  on  the  TlmerQ.   Rather  than  having  ACK  removed  from  the 
TimerQ  every  time  another  frame  Is  removed  from  SendQ  and  transmitted,  the 
"last_ACK"  variable  records  every  piggyback  ACK  and  just  waits  for  time-out 
to  remove  the  ACK  from  TimerQ.   (See  "frameinO"  for  details.) 

1f(  timeout_ACK  >  0  )  { 

1f(  SendEmpty( )  &&  last  ACK  !-  ModDec(Lp->ExpectedF) 

&&  Lp->state  !«~L  DISC  )  < 

SendC(FIACK.O);  /*   Send,  don't  set  "tics"  for 

timeouts  —  handled  by  "framem()"  when  SendO  empty.  */ 

} 

/* HEAR  Timeout  Processing */ 

/*  Put  HEAR  on  SendO  1f  Link  1s  CONNected  and  SendO  is  empty.   If  Link  is  in 
any  other  state,  either  it's  DISC  (and  HEAR  shouldn't  be  sent)  or  other 
timing  (waitlngDISC  or  waltingCONN)  will  result  1n  SendQ  entries.   When 
the  Link  enters  CONN,  HEAR  need  not  be  added  to  TimerQ,  since  every  entry 
to  the  CONN  state  adds  an  entry  to  SendQ  and  "f ramereq( ) "  will  then  start 
HEAR  timing  when  the  SendO  1s  empty.   Note  that  "f ramereq( ) ■  is  the  only 
place  where  HEAR  timing  is  Initiated,  since  it  most  closely  determines  the 
beginning  of  frame  transmission  and  is  the  most  reasonable  point  to  start 
timing  for  "idle  channel".   (HEAR  time-out  1s  processed  last  to  minimize 
the  waste  of  adding  HEAR  and  then  another  frame  to  SendQ  as  the  result  of 
other  time-out  actions.) 


V 


if(  timeout_HEAR  >  0  )  { 

if(  SendEmptyO  &&  Lp->state  «■  L  CONN  )  { 

SendC(FiHEAR.O);     /*  Send,  don't  set  "tics"  for  timeout 

--  handled  by  'framereq'  when  SendQ  empty  */ 

} 
}     /*  end  timeout  processing  block  */ 
>    /*  End  "select"  */ 


ENDLOOP 

#undef  NUMcntl 
#undef  Modlnc 
"undef  ModDec 
#undef  BETWEEN 
#undef  ReqHead 
#undef  ReqFree 
#undef  ReqEmpty 
#undef  ReqFul 1 


/*  Undeflne  all  private  'deflne's  of  'foutput'  */ 
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#undef  ReqAdd 
#unaef  ReqGet 
#undef  SendEmpty 
#undef  TlmerEmpty 
#undef  SendAdd 
#undef  SendGet 
#undef  TlmerAdd 
#undef  TlmerDel 
#undef  Sendl 
#undef  SendC 
> 
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/*  Requests  incoming  frame  via  framercv,     */ 

/*  passes  it  (or  error  Indications)  via      V 

/*  frameln  to  'foutput'  to  determine  what  to   */ 

/*  do  with  it.   Possibly  sends  it  "up"  to    */ 

/*  Network  Layer  via  Router . forwardmsg.  */ 

process  body 

f input (my_node. 1ndev, 1 1nkno,0utproc, Router, Serv, Lp) 

Fbuf  *fr; 

Action_t  ret; 

process  did  in  did; 

int  missing  =  0;     /*  Missing  pulse  counter  */ 

char  *dn  ■  "did  x" ; 

Lp->1  ■  wopen();     /*  Open  window  before  anyone  can  use  1t  */ 

/*  Create  Data  Link  Level  Input  process  */ 
did  ■  create  did  in(  indev,  Serv,  Lp) ; 
dn[strlen(dn)-1 ]  =  my_node; 
c_se t name ( die 1 , dn) j 

LOOP 

fr  «  within  PulseGap  ?  did . f ramercv( )  :  FNULL;  /*  Wait  for  a  Frame  */ 
/"  fr  >■  FMIN  •>  frame  address 
fr  ■■  FNULL  •>  missing  pulse 
fr  <  FMIN   *>  error  code      */ 
if  (fr  -•  FNULL)  { 

If  (m1ss1ng++  >■  PulseGone)  { 
missing  *  0; 
(vold)Outproc.f rame1n(  FNULL  ); 

>  else  < 

missing  ■  0;     /*  Ignore  previous  pulse  failures  —  received  Input.  */ 
ret  ■  Outproc.framem(fr);       /•  Tell  'foutput'  about  Input  and  */ 
switch  (rat)  {  /*  ..act  on  response  */ 

case  A_ROUTEMSG:       /*  'foutput'  says  "send  up  to  Network  Layer"  */ 
lf(  fr  <  FMIN  )  errmsg( nf input :  can't  sendup" . ( int )ret ) ; 
Router . forwardmsg ( 1 Inkno, f r->packet , f r->f rom, f r->to. 

(CH ) ( f r-> 1 en-FHDRs 1ze ) . f r->net_type ) ; 
break; 
case  A_IGN0RE:         /*  'foutput'  says  "No  further  processing"  */ 

break; 
case  A  BADframe:       /*  'foutput'  says  "Found  error  1n  frame"  V 
COUNT(badfrs);       /*  Count  bad  frames.  */ 
break; 
default:  /*  Unexpected  response  from  'foutput'  */ 

errmsg( "f Input :  bad  'ret ' " , ( 1nt )ret ) ;        /*  ..can't  happen..  */ 
break; 
> 

1f  (fr  >-  FMIN)  <       /*  If  received  a  frame.  */ 
Serv.relF(fr);       /*  ..we're  done  with  it.  */ 

)  /*  end  else  V 
EN0L00P 
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/*  Manages  a  node-wide  pool  of  Frame  Buffers  */ 

process  body 

service (numFrames) 

{ 

register  short  1;  /*  general  counter  */ 

Fbuf  *fpool ;  /*  fpool  ->  array[ numFrames]  of  Fbuf  */ 

fOe_t  *fO;  /*  fO  ->  array[numFrames+1 ]  of  FQe  */ 

#def1ne  fqHead  numFrames  /*  define  slot  for  list  head  */ 

/*  (I.e.,  highest  element  1s  "list  head")  */ 

register  Fbuf  *fp;  /*  general  usage  "/ 

register  fQe_t  *qp;  /*  general  usage  */ 

mt  avail  *  numFrames;  /*  Counts  "available"  Frame  Buffers  */ 

/*  Allocate  space  for  the  "fO"  array,  a  circularly-linked  11st  of  pointers 
to  available  ("free")  Frame  Buffers,  plus  extra  element  for  list  head. 

V 

1f(  (fO  "  (fOe_t  *)malloc(  (numFrames+1 )*s1zeof (fQe_t )  ))  ■■  NULL) 
errmsg( "getF :  can't  malloc  frame  1 1st" , numFrames) ; 

/*  Build  Frame  Buffer  pool  */ 
fpool  ■  (Fbuf  *)mal 1oc(numFrames*sizeof (Fbuf ) ) ; 

if(fpool  «  NULL)  errmsg( "getF :  can't  malloc  frames  1 " .numFrames) : 
if(fpool  <  FMIN)  { 

/*  Need  to  insure  that  FrameBuf  pointers  are  >■  FMIN.  (Retry)  */ 
free(fpool);     /*  Free  up  old  space  first  */ 

/*  Now  allocate  extra.  */ 
fpool  ■  (Fbuf  *)ma1 1oc(numFrames*sizeof (Fbuf )  +  ( mt)FMIN) ; 
1f(  fpool  ■■■  NULL  )  errmsg(  "getF :  can't  malloc  frames  2"  .numFrames) ; 

/*  Increment  fpool  enough  to  fix  problem.  */ 
fpool  «  (Fbuf  *)(( 1nt)fpool  +  (1nt)FMIN); 
1f(fpool  <  FMIN)  errmsg( "getF :  can't  malloc  frames  3' , ( int )fpool ) ; 

/*  Initialize  free-frame  linked  11st  (fO)  and  Frame  Buffers  themselves  */ 
for(  i -0, fp«fpool ,qp«fO;   i<numFrames;  !*♦, fp++,qp++  )  { 

1f(  fp  <  FMIN  )  errmsg( "getF:  Bad  FrameBuf  Alloc. ',1);   /*  Sanity?  */ 

fp->con  ■  conlDLE;       /*  Mark  FrameBuf  idle  */ 

qp->next  »  1+1;  /*  Forward,  backwards  links  */ 

qp->prev  «  1-1; 

qp->1tem  ■  fp;  /*  Linkage  to  Framebuf  */ 

/*  Set-up  linkage  to  fqHead  (and  fix  bad  link  at  beginning  of  list  */ 
qp«&fO[fqHead]; 

qp->next  ■  0;  qp->prev  •  numFrames-1;  qp->1tem  ■  FNULL;   /*List  Head  */ 
fO[0].prev  «  fqHead; 

/*  fO  now  contains  pointers  to  all  available  Frame  Buffers  */ 
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LOOP 
select  { 

(avail):        /*  If  any  avail,*/ 
accept  getF()  {        /*  get  a  frame  */ 

qp  ■  &fO[Remove(fQ,fO[fqHead] . next ,f qHead) ] ; 

ASSERT(qp  i-  &fQ[ fqHead] ) : 

if  {  (fp  ■  qp->1tem)->con  !-  conlDLE  ) 

errmsg( "getF :  11st  Fbuf  non-idle" ,qp-f 0) ; 
—  aval  1 ; 

fp->con  ■  0;         /*  Assumed  by  clients  */ 
treturn  fp; 
) 


or 


> 

EN0L00P 
> 

#undef  fqHead 


accept  relF(fr)  <       /*  Release  frame  */ 

if  (fr- >con  &  conlDLE)  errmsg( "rel F :  frame  already  IDLE" , f p-fpool ) j 

fr->con  ■  conlDLE; 

fp  ■  fr;  /*  Save  pointer  */ 

treturn;  /*  Allow  caller  to  continue  */ 

/*  Translate  fp  (1n  fpool  array)  to  corresponding  entry  in  fQ  array  */ 
/*  Then  verify  that  the  entry  points  back  and  Is  unlinked.  */ 
1f(  (1  ■  f p-fpool )  <  0  j|  1  >  numFrames 

||  f0[l].1tem  !»  fp  ||  f0[1].next  !-  Onull  ) 
errrasgt "relF:  Invalid  Frame  released" , 1 ) ; 
Insert(fQ, i .fqHead, fqHead);      /*  Insert  at  end  of  "fQ",  thus 

rotating  through  all  the  Fbufs  "/ 
aval 1++; 
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/*  A  cheap  timer  that  wakes  'foutput'  up  */ 
/*  every  ftlmerGap  seconds.  */ 

process  body 
f t1mer(Foutput ) 
{ 

LOOP 

delay  ftlmerGap; 

Foutput ,ftime( ) ;         /*  Tell  'foutput'  time  has  gone  by.  */ 

ENDL00P 
) 
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.TH  PR0T0  1  "17  December  1986" 

-UC  4 

-SH  NAME 

Proto  \-  Exercise  a  Link-layer  data  transmission  protocol 

.SH  SYNOPSIS 

.B  Proto 

[-r]  node-IDs  [  1  Ink-IDs. comm-device   ]  ... 

.SH  DESCRIPTION 

. I  Proto 

exercises  a  Link-layer  data  transmission  protocol  Implementation 

written  1n  Concurrent  C. 

The  Implementation  has  several  possible  Interfaces  to  the  user, 

selected  at  compilation  time  via  '-D'  options  to  the  Concurrent  C  compiler. 

These  interfaces  are  determined  by  the  presence  or  absence  of  the  Window 

Manager  screen  Interface  (part  of  the  Concurrent  C  'package')  and 

the  presence  or  absence  of  the  MDNITOR  Interface. 

The  absence  of  the  MONITOR  causes  all  MONITOR  input  (see  below)  to 

be  unrecognized,  and  also  results  in  the  MONITOR  not  being  created  as 

a  process  by 

.IR  Proto  . 

See  the  README  file  for  more  Information  on  the  compilation  options. 

.  PP 

In  general,  the  variously  compiled  versions  of  Proto  are  named  as  follows- 

.nf 

.ta  13 

\fBProto\fP    has  Window  Manager  and  MONITOR,  but  no  TRACE  lines  compiled. 

\fBtProto\fP    like  \fBProto\fP,  with  TRACE  lines  compiled  for  testing. 

\fBt1nyProto\fP        no  Window  Manager  or  MONITOR,  single  User  process. 

\fBnwProto\fP   no  Window  Manager  or  Users,  has  MONITOR 

\fBnomonProto\f P       no  MONITOR,  has  Window  Manager  and  2  Users 
-f  1 
.br 

The  \fB-r\fP  option  1s  only  valid  with  \fBt 1nyProto\f P  and  \f Bt1nyProto\f P . 
It's  appearance  (Immediately  following  \fBProto\fP)  will  cause  \fBProto\fP 
to  place  all  normal  terminal  output  (error  messages,  etc.)  into  a  file 
named  "Proto-stdout " . 

The  is  primarily  useful  with  the  'tty'  \f Icomm-device\fP  capability  (see  below) 
.PP 
The 

. I  node- IDs 

is  a  string  of  alphanumeric  characters;  the  first  character  becomes  the 
"name"  of  this  \fBProto\fP  node,  and  any  other  characters  become  aliases 
for  this  node. 
.PP 
The 
.1 

1 1 nk- IDs . comm-dev 1 ce 
-R 

arguments  each  describe  a  Link  (a  Link- layer  set  of  processes  connected  to  a 
peer  set  of  process  over  the 
.IR  comm-device  Interface). 
.PP 
The 

.1  link-IDs 

are  specified  1n  the  same  manner  as 
. IR  node-IDs  . 

The  first  identifier  is  taken  as  the  name  of  the  node  at  the  other  end 
of  the  Link. 

The  other  Identifiers  are  nodes  that  are  also  connected  to  the  other  end. 
The  Link  selection  algorithm  will  select,  where  possible,  a  Link  directly 
connected  to  a  node,  if  the  Link  is  "up  and  working".   Otherwise,  the 
first  "up  and  working"  Link  with  the  requested 
. I  node-name 
in  its  1 1st  of 
.1  link-IDs 
will  be  used . 
.PP 

.  I  Comm-device 
i  s  opened  by 
.B  Proto 
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with  an  input  file  descriptor  and  an  output  file  descriptor. 

Link-level  output  1s  placed  on  the  output  file  descriptor  and  link-level 

input  is  read  from  the  file-descriptor. 

The  "special " 

.  IR  comrn-devlce  s 

currently  supported  are  the  'pipe',  the  'cmd'  and  the  'tty'. 

The  'pipe'  forms  an  internal  "loop-around"  connection  between  the  input  and 

output  of  the  specified  Link. 

Any  output  is  just  echoed  back  as  Input  (useful  for  quick  tests?). 

.PP 

The  'cmd'  causes  \fBProto\fP  to  fork(2)  and  execv(2)  a  new  shell(see  sh(1)) 

arranged  such  that  typed  input  1s  sent  to  the  shell,  and  output  from  the 

shell  is  echoed  back  to  the  user. 

After  the  user  has  started  whatever  processes  desired  using  shell  commands, 

a  line  of  Input  (currently  "END-LEV1")  tells  \fBProto\fP  that  the  usual 

link-level  I/O  can  now  occur  to  the  executing  "commands". 

The  "commands"  should  use  file  descriptor  0  to  read  link-level  output 

from  \fBProto\fP  and  file  descriptor  1  to  send  responses  back  to  \fBProto\fP. 

.PP 

The  'tty'  causes  \fBProto\fP  to  use  file  descriptor  O  for  this  Link's  input 

and  file  descriptor  1  for  it's  output. 

Since  \fBProto\fP  will  start  using  this  immediately,  1t  should  always 

appear  as  the  last  \f II ink-IDS,comm-device\f P  argument. 

.PP 

Any 

. I  comm-devlce 

name  other  than  the  "special "  ones  above  are  assumed  to  be  of  the  form 

. I  device-name 

or 

.IR  device-name1 ,dev1ce-name2  . 

The  latter  form  will  cause  \fBProto\fP  to  open(2)  \f Idev1ce-namei\f P 

for  reading  and  \f Idevice-name2\fP  for  writing. 

Link-level  output  for  this  Link  will  be  directed  to  \f Idev1ce-name2\fP 

and  input  will  be  read  from  \f Idevice-namei\f P . 

If  the  "non-comma"  form  of  \f Idevice-name\fP  1s  used,  it  is  opened  for 

both  Input  and  output,  and  all  link-level  I/O  is  done  through  it. 

•  PP 

As  an  example, 

.br 

-sp 

.nf 

nwProto  -r  FARM  b12,pipe  c3b2 . /dev/tty03  rlch.tty 
.sp 
.f  1 

would  set  up  the  "nodelD"  as  'F'  with  'A',  'R',  and  'M'  as  aliases  for  'F'. 
Three  Links  would  be  set  up,  one  named  'b'  that  is  connected  to 
a  node  named  'b'  that  1n  turn  claims  to  also  be  connected  to 
other  nodes  named  '1'  and  '2';  actually,  as  a  'pipe',  all  output  is  just 
echoed  back . 

The  Link  named  'c'  could  send/receive  messages  using  /dev/tty03;  link  'c'  would 
handle  messages  to  nodes  'C.  '3',  'b'  and  '2'. 

Messages  to  node  '2'  would  attempt  to  route  over  the  Link  to  node  'b' 
1f  'b'  is  "up  and  working",  otherwise  node  'C  would  be  attempted. 
Messages  to  node  'C  Itself  would  route  to  node  'b'  If  the  Link  to  node  'C 
was  not  "up  and  working",  or  to  node  'r'  if  bothe  'b'  and  'c'  were  not 
"up  and  working". 

Link  'r'  would  actually  use  file  descriptors  0  and  1  for  I/O,  so  the  whole 
\fBProto\fP  command  should  be  executed  from  another  Invocation  of  \fBProto\fP. 
probably  using  the  'cmd'  capability. 

SH  NO  WINDOW  MANAGER 
This  interface  results  in  a  single  'user'  process  with  access  to  the  terminal. 
All  input  is  directed  to  the  'user'  process,  and  all  user-level  output  1s 
directed  to  "stdout". 

Error  output  is  directed  to  both  "stdout"  and  "stderr",  which  may  be 
re-directed  by  the 
.IR  sh  (1) 
"2>"  syntax  when 
. I  Proto 
1 s  1 nvoked . 
.PP 
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Input  to  the  'user'  is  handled  by  examining  the  first  character  of 

each  input  1 1ne. 

The  action  taken  for  particular  characters  is: 

.nf 

.  ts  9 

Character       Action 

~D  (EOF)        Terminate  'user'  process. 

/       Term  1 nate  ' user '  process . 

+  x      Send  CONNECT  request  to  Link  'x'  processes. 

\-x     Send  DISCONNECT  request  to  Link  'x'  processes. 

Send  characters  following  '*'  out  on  all  CONNECTED  Links. 

(This  "Broadcast"  capability  is  currently  unimplemented. ) 
%       Send  all  characters  from  the  filename  following  '%' . 

(Also  currently  unimplemented.) 
.sp 
.f  1 

Otherwise,  the  first  input  character  1s  assumed  to  be  a 
.1  I1nk-ID 
and 

.B  Proto 

will  attempt  to  find  an  appropriate  Link  over  which  to  send 
the  message  (characters  following  the 
.IR  1 1nk-ID  ). 
. SH  MONITOR 

The  'MONITOR'  process  accepts  all  'User'  input  and  commands  (and  is 
considered  User  O  by  other  processes),  but  in  addition  can  accept  some 
other  commands. 
These  are  currently: 
.nf 
.  ta  9 

Command  Action 

-X      Abort  all  \fBProto\fP  processes,  restore  TTY  characteristics. 
~Mx     Enter  the  "ntonvar"  interface  mode.   This  allows  access  to  MONITOR 

variables  for  the  Link  named  'x'.   Exit  the  mode  with  a  '0'. 
.sp 
-f  i 
.PP 

The  "monvar"  interface  allows  access  to  "MONITOR  variables"  that  control 
TRACE  output  and  data  collection  during  execution.   The  Interface  commands 
are: 
.nf 
.ta  9 

Command  Action 

0       Exit  "monvar"  Interface  mode. 

d       Display  all  MONITOR  variables  and  their  values, 
d  var   Display  value  of  MONITOR  variable  named  "var". 
s  var    Set  MONITOR  variable  "var"  to  1. 
r  var   Set  MONITOR  variable  "var"  to  0  (i.e.,  "reset"), 
.sp 
.f  1 

Further  Information  on  the  use  and  usefulness  of  the  MONITOR  variables 
is  contained  In  the  \fBProto\fP  README  file. 
-SH  DIAGNOSTICS 

Diagnostics  are,  hopeful ly.  sel f  explanatory, 
.sp 

When  \fBProto\fP  is  started,  the  list  of  "escaped"  character  codes  (in  octal) 
1s  printed,  along  with  the  corresponding  character  (in  octal)  what  will  be 
used  as  a  replacement. 
.SH  BUGS 

The  user  interface  1s  fairly  crude,  but  it  allows  sufficient  access 
for  tracing  and  debugging  of  the  protocol. 
If  the  Window  Manager  Interface  1s  used  and 
.B  Proto 

is  killed,  the  "tty"  Interface  will  usually  not  be  restored. 
Try: 
.br 
.sp 

.TP  10 

stty  -raw  -cbreak  echo 
.br 
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■  sp 

to  restore  most  functionality. 

.PP 

The  set  of  MONITOR  variables  Is  probably  not  correct  for  total  prove-in 

of  the  protocol  implementation,  since  they  were  invented  as  needed  during 

the  implementation. 
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This  report  presents  a  data  link  protocol  designed  by  analyzing  protocols  in  the  literature, 
choosing  one  as  a  base  and  extending  that  base  with  mechanisms  taken  from  other 
protocols.  The  extended  protocol  is  described  in  some  detail.  Time  sequence  diagrams 
are  used  to  demonstrate  the  operation  of  the  protocol  under  several  transmission  failure 
conditions. 

An  implementation  of  the  protocol  in  Concurrent  C  is  also  presented.  A  test  environment 
that  provides  monitoring  and  selective  control  over  the  implementation  is  described. 


